[Mageia-dev] How broken are RPM dependencies allowed to be?

Wed Dec 14 12:30:33 CET 2011

On Wed, Dec 14, 2011 at 09:14, Dan Fandrich <dan at coneharvesters.com> wrote:
+> On Wed, Dec 14, 2011 at 09:49:15AM +0200, Buchan Milne wrote:
+>> This is unsupported. Maybe you should instead contribute documentation that
+>> makes this more explicitly obvious, but it is a well-known rule in Mandriva and
+>> Mageia (and usually applies to other distros as well).
+>
+> 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.
+
+> 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.
+
+>> If this weren't the case, there wouldn't be a need for backports ...
+>
+> Backports are nice in that they are leaf packages that don't generally
+> require a ton of newer libraries be installed as well. Installing a
+> single package of any complexity from a newer distribution often results
+> in a cascading series of new packages to resolve all the dependencies.
+> But it's often expeditious to upgrade simpler packages in that way in
+> cases when the system can't completely upgraded right away.
+>
+> It's possible to handle that kind of case reliably, but I understand that
+> it would be more work to get the dependencies just right. Many library
+> authors put plenty of effort into maintaining binary compatibility across
+> releases just so this sort of thing is possible. But even if this isn't an
+> officially-supported mode of operation, problems like the one I described
+> above can still result in broken systems if the dependencies aren't
+> correctly described.
+>
+>> 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?
+>
+>> 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.
+>
+>> Supporting the use case of installing any random package from a different
+>> release will take more effort than just adding and maintaining a version on one
+>> perl-base dependency.
+>
+> Yes, it will, but it can be automated to a certain extent. There just has to be
+> a will to make sure that even the corner cases work.
+>
+>>>> Dan
+