On 14 December 2011 10: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.
This is bullshit. urpmi will upgrade perl itself first (with glibc, rpm & perl-URPM). > 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. This is totally unrealistic. If someone is fool enough to perform a live upgrade on a server still serving requests, it deserves being shoot. Twice. One usually pulls a server out of trafic, upgrade it, then put it back in use. And keeps HA by keeping another old server responding. That's not a valid use case. >> Installing packages individually from one release on another release is not >> supported. Either upgrade the entire distro first, or stick to packages from >> the version you are on. However 'upgrade from release to Cauldron', when done >> correctly, should usually work as expected. > > Yes, "usually". Is Mageia the operating system that works reliably 95% of the > time? This will break on every distro. >> But, in supported use cases, urpmi *does* ensure that all the pieces to keep >> urpmi are upgraded in one transaction. > > But only if the dependencies are set correctly. And my original bug report on > that has just now been closed as WONTFIX. Once again, your report has nothing to do with urpmi. Urpmi doesn't depends on quite a lot of packages and it WILL upgrade them first then restart.
