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

Wed Dec 14 01:31:27 CET 2011

I raised a bug ticket on drakxtools (#3731) because the RPM in Cauldron
+installs without complaints in Mageia 1 but won't work there because
+it requires a newer version of perl. The perl dependency in the
+RPM is listed as "perl-base" when it should really be something like
+"perl-base >= 5.14.2" (Mageia 1 ships with version 5.12.3).  The response
+I got was that such an upgrade (from release to Cauldron) wasn't supported
+and this bug was likely a wontfix.
+
+I looked for a policy that covers this kind of situation and found nothing
+clear.  The closest I found was this:
+
+    Packages should only contain Requires if those are absolutely
+    necessary for the program to work correctly...Packages must not
+    contain explicit Requires on libraries except when absolutely
+    necessary. When explicit library Requires are necessary, there should
+    be a spec file comment justifying it...Packagers should revisit an
+    explicit dependency as appropriate to avoid it becoming inaccurate
+    and superfluous.
+
+What isn't in the policy is what "absolutely necessary" is. It is clearly
+"absolutely necessary" from a technical perspective that the newer
+drakxtools have the newer perl installed for it to work. But, is it
+necessary to list that version dependency in the RPM?  IMHO, it is, given
+that the perl version in the currently-shipping Mageia distribution is
+too old to support it. That seems to me to be the kind of use case for
+which versioned requires were invented.
+
+The other argument would be that you shouldn't put any versioned
+requires on packages that are shipping along with the dependent
+package. In essence, as long as all the packages in your system come
+from the same Mageia release, you'll be fine.  I think this is much too
+lax, and won't even really work on Cauldron because there can be so many
+possible combinations of package versions. It could also break upgrading a
+system in place to a new distro version, as urpmi could choose to upgrade
+the dependent package first and leave the newer versioned dependency
+until much later, leaving the system in a broken state in the meantime.
+It also ignores one of the most powerful features of RPM and can end up
+causing "DLL hell".
+
+What makes the most sense to me is to use versioned requires whenever
+technically necessary, but put a limit on how old a version can be before
+it's dropped.  So, if one package absolutely needs a minimum version of
+another, that version should be listed as long as an older version shipped
+at some point in the past 3 years or 6 releases (or something along those
+lines).  After then, the version can be dropped in the spec file. Checking
+for older versions that could be dropped could even be automated.
+
+That, to me, strikes a reasonable balance between maintaining flexibility
+in being able to switch between package versions and maintainability of
+the spec files and RPMs themselves.
+
+>>> Dan
+