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
