Bug#649319: debootstrap: cannot handle perl-modules 5.12.4-6 and 5.14.2-5 both being in sid

[Colin Watson <cjwatson@ubuntu.com>]

On Mon, Nov 21, 2011 at 02:15:18PM -0400, Joey Hess wrote:
> Note that debootstrap should not need to install perl at all, and I made
> a NMU yesterday that should remove the dependency that was pulling it
> in.

It will always have to do so for --variant=buildd.  Note that the
original bug report spoke of this breaking pbuilder and mk-sbuild.

> This is an unusual situation; I think DAK included both perl-modules
> because it's arch all and different versions are needed on different
> architectures.

Sort of.  It included it because libperl5.12 was still in the archive,
and it doesn't remove Architecture: all binaries until all the
Architecture: any ones have gone.  Once libperl5.12 was decrufted,
perl-modules went away too.

The old perl-modules wasn't actually required for bootstrapping even a
buildd chroot in anything other than the extremely early stages of the
Perl 5.14 transition.  There was a long period where libperl5.12 was
hanging around for the sake of the odd leaf package that failed to build
with 5.14.

> It follows that there's no single right version -- a dependency
> resolver is needed to pick the right one. It does not make sense to
> put a dependency resolver in debootstrap, so the place to fix this
> kind of breakage seems to be in the archive, and not in debootstrap.
> 
> Preferring the later version might be a better heuristic on average.

I agree that in the general case a dependency resolver is needed.  However, I
didn't intend my change to be any more than a better heuristic.

I think the change to keep old versions of Architecture: all packages in
the archive is generally a good one; it smooths out problems caused by
build skew across architectures and improves the chances of unstable
being installable.  Even though testing exists, this kind of measure to
make unstable a bit less unstable seems reasonable enough.

Given multiple versions of a package in the Packages file, debootstrap
can clearly only succeed if the archive is such that there exists at
least one version that it can pick and have everything within its
desired base set be consistent with that.  For the sake of argument,
let's say there are two packages, which means that there are two ways
things can go wrong:

 1) The desired base set is only consistent with the older version, and
    debootstrap's heuristics pick the newer version.  This is probably a
    grave bug in unstable in any event and will normally be cleaned up
    quickly by binNMUs or similar (particularly given the release team's
    very proactive approach to transitions in recent times).

 2) The desired base set is only consistent with the newer version, and
    debootstrap's heuristics pick the older version.  The only way we
    can deal with this is to complete whatever library transition is
    involved so that the old Architecture: any binaries that are keeping
    the older Architecture: all package in Packages can be removed.
    This is often a time-consuming process; in the best case, it is no
    quicker than the solution to 1), and in the worst case, it may get
    snarled up in build failures and could easily take days or weeks.

For this reason, I think that the debootstrap heuristic I implemented is
strictly better than the previous one.

Cheers,

-- 
Colin Watson                                       [cjwatson@ubuntu.com]