At the moment updates to RHEL4 base and Extras channels are merged on the
/errata/ page (see http://rhn.redhat.com/errata/). Similarly RHEL3 base and
Extras are merged.
These need to be split asap, so that RHEL4 Extras and RHEL3 Extras packages have
their own, separate, errata lists.
Justification: A number of significant Critical security issues are affecting
Extras packages over which we have limited control, but this is affecting the
perception of our overall security, even though Extras is meant to be an
unsupported add on. By merging them we increase customers expectations that
packages in Extras will be treated in the same way as Base.
Text on /errata/ page would be
"Red Hat Enterprise Linux Extras (v. 3)"
"Red Hat Enterprise Linux Extras (v. 4)"
(There is no need to have separate pages for AS, WS, ES, Desktop etc -- channels
can be rerouted and not included in multiple products)
Channel names for reference:
Security team will QA this change when ready.
Seems to work nicely, both through /errata/ and through RHN once logged in.
However one minor issue
Looking here: https://rhn.webdev.redhat.com/errata/RHBA-2004-556.html
the SRPMS and ia32 rpms are listed 4 times (I guess once each for AS, ES, WS,
Extras is a channel distinct from AS, ES, WS, so I think we should continue as
is and not separate have separate extras for each variant. Perhaps put in a
bugzilla against the /errata/ pages so that duplicated files for Extras packages
don't show up 4 times.
I've asked the dba's to push this change to QA.
The Extras products won't be sorted quite as nicely as they were on dev, b/c
doing so would require a pl/sql change, which would require us to take an outage
to push this change. The sorting will be fixed for the rhn400 release which is
scheduled for mid-August timeframe.
The change is now on QA. Please verify at:
Mark, have you guys had a chance to verify this in qa? Thanks.
Sorry, yes this looks fine :- even the positioning at /errata/.
(Subject to the same problems as #4 where extras rpm's are listed multiple times
-- which can be fixed later and not a showstopper for this change).
This has been pushed to production.
Thank you for your fast response to this issue!