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

[nicolas vigier]

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.