On Tue, Dec 30, 2003 at 01:55:01AM -1000, Warren Togami wrote: > Axel Thimm wrote: > >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. The unofficial rpm errata are an improvement, nobody denied that. If Red Hat decided not to do the upgrade nonetheless, there must be a true reason. And if that reason is that upgrading the rpm database format is occasionally eating your database, it is a severe reason, too. > 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. I have never ever had two processes access the same rpm database in chroot builds, and I still get a corruption every few days in the >= RH8.0 chroots. > <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> They would have a better case in shutting down customer trust with doing this with the kernel rpms. On the contrary, I suppose that they estimate they'd be breaking more than fixing. Their estimation could be wrong, and we may know better, or the other way around. Do you want to risk it? If you want to be paranoid: Probably RH is waiting for a scape goat to impose the transition. ATrpms did play scape goat, but there I'm not wearing the conservative legacy cap (or is that a fedora? ;), and I need a recent rpm for maintaining only one specfile for all four distros, which is something legacy doesn't need. > >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. I wrote "up to", didn't I? ;) > > 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? No, nobody uses --rebuilddb other than fixing the broken rpm databases. If --rebuilddb would be the culprit, the problem would have been solved, as it would never be issued. > 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. I think you remember wrong or vice versa, Jeff always suggests using it, in my rpm-list archive for example three weeks ago for the last time. Also on quoted mails from Jeff at rpm.org. In any case rpm database corruption is there since 4.1 upwards until today, in various degrees, but always present. > [...] 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, > [...] I am giving the community only the roadmap and infrastructure > to do it. This initiative is counting on YOUR support or it will > fail. Infrastructure is only useful for managing content. I suggest to invest man power in creating the content first and then improving organization. The actual developers themselves should decide on an infrastructure, so let's see who will be doing legacy rpm work in January. I believe that there are more consumers than developers on this list, and that Progeny's $5 offer reduced the pain and need for fedora-legacy. Should Progeny not be up to the task (which I believe it will do fine), people will come back to fedora-legacy, but currently there are only ghost city planers left here. ;) > > > [... epoch promotion ...] > > 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? No, that wasn't apt's misbehaviour, but your's ;) And it wasn't recent either. I found an ugly bug yesterday when using apt-0.5.15cnc5 on RH9/rpm 4.2. -- Axel.Thimm@xxxxxxxxxxxxxxxxxxx
Attachment:
pgp00017.pgp
Description: PGP signature
