On Wed, Dec 14, 2011 at 11:30:33AM +0000, Pascal Terjan wrote: > On Wed, Dec 14, 2011 at 09:14, Dan Fandrich <[email protected]> wrote: > > I can understand that my particular case is unsupported, but I described > > a different, supported, scenario that would also fail due to this problem. > > To reiterate, a distribution upgrade from 1 to 2 (once it's finalized) > > could involve urpmi first upgrading the perl-dependent package but avoid > > installing the new perl itself until the end of the upgrade, which could be > > hours or (if interrupted) days later. > > During an upgrade urpmi starts by updating what it uses (perl, rpm, > few other things, itself) and then restarts.
That has nothing to do with the problem in general. This same issue could occur with any package that relies on a newer library (even just a newer point version) but without mentioning that newer library version as a versioned require. That's the more general issue of which my perl-using example was but one example. > > During the entirety of that time, > > that package would be unusable. If that package happened to be a key CGI > > script for a web site, the entire site would be down for that entire time. > > That would not be prevented. The result would be that you need to > install thousands of packages in the same transaction as they are all > required by each other, and nothing would prevent your CGI from being > at the end of the transaction which will happen hours or days later. All packages are not required by each other. On my system, 13% of packages are leaves that nothing depends on. 15% depend on nothing other than glibc, libstdc++ or bash. Another 14% have a single other dependency, in most cases a tightly-coupled library built from the same source code. So trying to argue that a transaction must install thousands of packages is specious. And RPM's installation sequence is designed to minimize the window when software is unusable during an upgrade. >>> Dan
