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

Wed Dec 14 23:37:37 CET 2011

On Wed, 14 Dec 2011, Dan Fandrich wrote:
+
+> On Wed, Dec 14, 2011 at 12:31:36PM +0100, Thierry Vignaud wrote:
+> > On 14 December 2011 10:14, Dan Fandrich <dan at coneharvesters.com> 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).
+> 
+> What does perl have to do with this?  It's a general problem that could
+> happen with any upgrade where version dependencies aren't listed correctly.
+> 
+> > > 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.
+> 
+> Once again, you're looking at this specific example and missing the general
+> case. This problem can happen even when installing a batch of bug fixes within
+> a single release. The time span would hopefully me more on the order of minutes
+> than hours, but the problem remains the same.
+
+We usually avoid pushing new incompatible perl version as update on
+stable releases.
+
+> 
+> > This will break on every distro.
+> 
+> Only those with broken dependencies. Plenty of people use Debian unstable, for
+> example, but in my experience, their dependencies are much more extensively
+> versioned.  Libraries of the same SONAME are generally backwards-compatible,
+> so there's nothing fundamentally preventing this from working. But, it
+
+Dependencies based on SONAME are already added, because it can be done
+automatically.
+
+> does mean extra effort and I understand if that's why it isn't being
+> done. But if that's the case, then when are versioned dependencies
+> ever acceptable?  The arguments I've been hearing (i.e. never try to mix
+> releases & don't bother trying to use your system during any kind of urpmi
+> update) ultimately mean that they could be entirely removed everywhere.
+
+Versionned dependencies are added when they are needed to allow correct
+updates on stable release or upgrades from one release to an other
+(installing all available updates, not only some of them), for example
+to require installing some packages in the same transaction. Or when
+the dependencies can be detected and added automatically. But I don't
+think you should expect to be able to take any package from any release
+and install it on an other release with accurate dependencies.
+
+