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/010430.html | 131 +++++++++++++++++++++++++++ 1 file changed, 131 insertions(+) create mode 100644 zarb-ml/mageia-dev/2011-December/010430.html (limited to 'zarb-ml/mageia-dev/2011-December/010430.html') diff --git a/zarb-ml/mageia-dev/2011-December/010430.html b/zarb-ml/mageia-dev/2011-December/010430.html new file mode 100644 index 000000000..560328fd3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-December/010430.html @@ -0,0 +1,131 @@ + + + + [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 20:42:32 CET 2011 +

+
+ +
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.
+
+> 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
+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.
+I really just want to have an agreed policy so I know which dependency bugs
+I find are worthy of being fixed.
+
+>>> Dan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

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