From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/2011-December/010414.html | 141 +++++++++++++++++++++++++++ 1 file changed, 141 insertions(+) create mode 100644 zarb-ml/mageia-dev/2011-December/010414.html (limited to 'zarb-ml/mageia-dev/2011-December/010414.html') diff --git a/zarb-ml/mageia-dev/2011-December/010414.html b/zarb-ml/mageia-dev/2011-December/010414.html new file mode 100644 index 000000000..81db36a6a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-December/010414.html @@ -0,0 +1,141 @@ + + + + [Mageia-dev] How broken are RPM dependencies allowed to be? + + + + + + + + + +

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

+ Dan Fandrich + dan at coneharvesters.com +
+ Wed Dec 14 10:14:59 CET 2011 +

+
+ +
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 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.
+
+> 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
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1