[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: RPM upgrade discussion



If this mail is too long: You probably don't want to upgrade rpm for
doing conservative, backported (security) bugfixes. Also my
recommendation would be to use Progeny's services, or go straight to
RHEL2/3, as I doubt that in two days legacy will be offering security
rpms.

On Mon, Dec 29, 2003 at 11:36:45PM -1000, Warren Togami wrote:
> As we discussed earlier, Fedora Legacy will require an upgrade of rpm as 
> a requirement for all users who choose to use our repository.  It is 
> quite clear that we agree upon the rpm upgrade for RH8 and RH9 due to 
> the major stability problems associated with those versions.

Personally I would also upgrade rpm (and in ATrpms' legacy support I
am doing so), but for the target group of legacy I would question this
issue for the following reasons:

o Red Hat never made rpm.org's errata official for any reasons they
  may have. I suggest asking why. Probably they do not consider the
  rpm upgrades stable enough. This is a strong signal not to go that
  way.

o rpm up to 4.2.1 still eats up your database occasionally. rpm 4.2.2
  hasn't any indication in the changelog about having found the nasty
  bug (which is probably not in rpm, but db4). It is so badly
  reproducable that Jeff hasn't had a chance to nail it, I guess. But
  any chroot packager with automatic rpm installs/erases can sing a
  song about random rpm database corruptions. From ATrpms' users'
  aspect I must admit a big improvement in RH8.0/9 when upgrading to
  4.2.x. But since Red Hat has not offered official errata for it, I
  would still hesitate.

o legacy is supposed to continue Red Hat's way of conservative
  backporting fixes (which BTW should include RH's naming conventions,
  even if I am the first to consider them broken). For rpm this would
  mean identifying the salvaging patches in rpm 4.2.1 and backporting
  them to RH8.0/9's rpm 4.1/4.2. That's quite a hammer, considering the
  number of patches that went in to fix an issue, which is still not
  totally fixed.

ATrpms' "legacy" support is not a conservative, bugfixing and security
fixing approach, it is far more functional oriented. It is also much
easier for administring the same package for 4 different distros, but
all this is not needed in legacy. If it were, you could simply use
ATrpms. legacy users will most certainly wish to follow the path of
least surprise.

For the above open issues I would consult Jeff Johnson, the maintainer
of rpm. I know he tried to push out errata for rpm, but obviously none
were issued. He should know the reasons best, and I his advise should
be heavily weighted for legacy's decisions. Warren, didn't you say you
wanted to ask him?

RH issued 6 updates for RH7.3 in December, e.g. one every five days. I
think this can be handled without touching rpm. Updates for
RH7.3/RH8.0/etc. have been mostly for different versions, with
different specfile etc. So you don't gain much with syncing the
infrastructure accross them. It's better to invest the man power in
monitoring the security lists and backporting those fixes. It is not
an easy task and you should consider 6 new upcoming security holes in
RH7.3 in January 2004.

That's why I would suggest to simply set up a repository today,
apt/yum or not enabled. People care less about the infrastructure,
than about having their web server shredded to pieces, because legacy
is still talking academia, while security announcements go
unnoticed. Even if users would have to install security fixes manually
with 'rpm -Uhv http://downloads.fedoralegacy.org/path/to/RH7.3/rpms/fixed.rpm'
they would be happier than having the best rpm/apt/yum infrastructure
with no contents ;)

Currenty I think the only option is to go with Progeny or
RHEL. fedora-legacy is still deep in the design and planning phase,
debating about upgrading rpm or not (which started in October), and
there is no indication that the reaction time to any security
announcements will be better. Just imagine another do_brk()-like bug
in the kernel on January the 1st.

> Any RPM upgrade that is included will only be done so after
> extensive testing and verification that it does not introduce any
> other problems.

Any rpm version >= 4.1 will eventually eat up your rpm database. So
much has been tested and confirmed by all parties.

> Unanswered Questions for Discussion:
> 1) What changed about the rpm epoch promotion behavior between rpm-4.2 
> and rpm-4.2.1?  Can somebody please explain this with details and 
> concrete examples?  I need to understand why we need to keep the old 
> promotion behavior for the RH9 rpm upgrade as some have mentioned earlier.

That is not a real problem, that part of the code could be easily
adjusted. I recently looked into it, because of apt's recent
misbehaviour in epoch promotion.

> 2) Should we upgrade to rpm-4.2.x for RH7.x?  While the benefit for 
> apt-get would be minimal, the benefit for yum would be immense as that 
> would enable the use of yum-2.x.  Another key benefit would be 
> compatibility with the newer RPM GPG signatures.

On Tue, Dec 30, 2003 at 01:44:59AM -0800, Chuck Wolber wrote:
> RPM 4.0.4 is just so damn stable, it'd be hard to risk an upgrade. Also, I
> must express a bit of ignorance here when it comes to yum, as I didn't
> realize that *adding* yum would require an RPM upgrade.

This is not really true anymore. There is work underway for allowing
almost all of yum 2.0 to run on a rpm 4.0.4 and python 1.5.2
system. It has not landed yet, and we should allow more time for it,
but it is a non-issue anymore.

apt-get is probably the best distribution mechanism available for
legacy. It has proven solid for the legacy releases (if one attributes
the triggered rpm database corruptions to rpm, apt/synaptic have taken
quite some unneccessary blame for it).

On Mon, Dec 29, 2003 at 11:36:45PM -1000, Warren Togami wrote:
> 3) Which specific RPM versions should we use?  In my personal experience 
> rpm-4.2-1 from rpm.org and rpm-4.2.1 from FC1 both work very well on 
> RH9, while rpm-4.1.1 works great on RH8, although librpm404-4.0.5 is 
> needed to maintain compatibilty with some packaging tools of that era.
> 
> Should we upgrade to rpm-4.2.x on RH7.x, RH8 and RH9, or use the above 
> mentioned versions?

On Tue, Dec 30, 2003 at 01:44:59AM -0800, Chuck Wolber wrote:
> Stability is more important than any new feature.

I agree that stability and security are the most important (or maybe
even the only) aspects of what people want from legacy.

On Mon, Dec 29, 2003 at 11:36:45PM -1000, Warren Togami wrote:
> Axel do you have any improvements to rpm-4.2.x series for the older 
> distributions that we should include?  I understand that you have a set 
> of very well tested rpm upgrades.

Yes, but see above about different scopes of a legacy and a feature
supporting approach.

For Xmas I had wished for a common RH errata for rpm for the running
RH versions. Unfortunately Santa considered me naughty :(
-- 
Axel Thimm physik fu-berlin de

Attachment: pgp00016.pgp
Description: PGP signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]