RPM upgrade discussion

Tue Dec 30 11:55:01 UTC 2003

Axel Thimm wrote:
> 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.

I strongly disagree, as anyone that has seriously used the rpm upgrades 
knows that they are night and day better than the default versions.  I 
think the only concern they had was the tiny amount of complications 
that could occur during the upgrade itself.  We can mitigate the 
potential problems with a very exact HOWTO for new users of Legacy that 
says how to kill all other processes that could possibly contend for the 
lock of rpmdb to ensure that the upgrade itself goes without a deadlock.

> 
> o rpm up to 4.2.1 still eats up your database occasionally. rpm 4.2.2

But this is true of rpm-4.1 and rpm-4.2 too.

>   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.

Does that have anything to do with --rebuilddb?  I really think it is a 
huge mistake that people keep suggesting --rebuilddb.  I seriously have 
NEVER used it since around RH7.3.  Everything I can remember at the 
moment, jbj suggested that it really is useless to use --rebuilddb after 
the rpm deadlock of RH8 or RH9.  The only thing you need to do is wipe 
out the /var/lib/rpm/__* files.

There is also the case with --rebuilddb where it corrupts stuff in your 
rpmdb if you have certain types of GPG keys imported into your rpm database.

> 
> 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.

Well reasoned, and especially given the news about yum-2.x for rpm-4.0.4 
this makes a good case for not upgrading RH7.x.  Somebody ping Seth 
about this and ask for a status report please.

> 
> That's why I would suggest to simply set up a repository today,
> apt/yum or not enabled. People care less about the infrastructure,

Already done, for RH8 and RH9 as the plan said we are using fedora.us 
"updates" channel.  "updates-testing" is coming soon along with the 
RH7.x channels.  I am creating 7.2 and 7.3 only for now unless 
developers seriously want to work on others.

> 
> 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.
> 

Realistically you are correct, as I am currently in doubt about the 
seriousness of intent to do actual work from developers.  I was very 
disheartened in the last month that no community members were seriously 
pushing this forward, forcing me to take the initiative or absolutely 
NOTHING would happen.

It would be a damn shame if Legacy fails, because some companies had 
already put money into it (EV1's $1K computer for Jesse), and other 
companies like Pogo willing to throw lots of money, time and resources 
into making it a reality.  It would also be an extreme benefit for the 
community to have updates available for all old distributions for a 
while longer than upstream's EOL.

While I see the importance of Legacy, I personally am pushing this 
forward to launch on borrowed time since it appears that it wouldn't 
happen otherwise.  I am giving the community only the roadmap and 
infrastructure to do it.  This initiative is counting on YOUR support or 
it will fail.

> 
>>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.

Which misbehavior?  Was this when fedora.us began adding Epoch: 0 to all 
packages and old apt compared 0 > missing?  In any case we don't need to 
worry about this anymore because apt now does the right thing, and the 
python bindings (due to a fortunate bug) always did do the right thing.

I'm glad to hear that it isn't a real problem though.

>>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.

That sounds promising.  If that is available that almost totally 
nullifies any need to upgrade RH7.x's RPM.

> 
> 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).

+1 totally in agreement.

> 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 :(

<paranoid>
Methinks continuing the broken RPM of RH8 and RH9 is incentive to 
upgrade to a working distribution, like FC1.  Or maybe there's business 
motives like a certain four letter acronym that begins at $129/yr. =)
</paranoid>

Warren