Bug#630399: perl: multiarch libc and partial upgrades

[Niko Tyni]

On Tue, Jun 21, 2011 at 10:37:57PM +0300, Niko Tyni wrote:
> On Tue, Jun 21, 2011 at 10:03:29AM -0500, Jonathan Nieder wrote:

> > Aside from "perl -V::libpth" itself and the perl build process, the
> > only code I can find that cares about libpth is the DynaLoader module
> > (and hence ExtUtils::Embed, etc).
> > 
> > Do you remember why DynaLoader is in perl-base and not perl-modules?
> 
> It's used to load all XS extensions like POSIX.so, Socket.so and so forth.
> However, I can't see why that functionality would need anything from
> libpth.  This needs to be checked properly of course.

OK, I see DynaLoader first tries to locate the plugin to be loaded in
the perl directories (/usr/lib/perl/5.12 and so forth) and falls back
to dl_findfile() if that doesn't succeed. The dl_findfile() function
looks in $Config{libpth}.

Obviously all the plugins in perl-base are in the perl directories, so
having a perl binary with a wrong $Config{libpth} on the system does not
affect basic module loading functionality.

Now, DynaLoader::dl_findfile() is a public function that could theoretically
be used by a Perl program to locate (say) libc.so, so this can be argued to
be part of the Essential functionality of perl-base. However, I very much
doubt any maintainer scripts in Debian rely on that.

Based on this, I think it's feasible for libc6 to Break just perl-modules.
Of course, this can be revisited in case it causes actual upgrade problems.

> > > On Tue, Jun 21, 2011 at 01:46:32AM -0500, Jonathan Nieder wrote:
> > 
> > >> Ah, here we go.  Based on how Configure computes libpth, what I should
> > >> have said is gcc-4.6 (>= 4.6.0-12).
> 
> > Make that gcc-4.6 (>= 4.6.0-13).  Reasons:

[...]

> > I don't know whether (2) is important.  If it's not, a simpler
> > approach would be to convince Configure to be trusting enough to use
> > use-provided paths even if the directory does not exist.  That way,
> > there would be no need for new build-dependencies, aside from dpkg-dev
> > (>= 1.16.0) for "dpkg-architecture -qDEB_HOST_MULTIARCH".
> 
> Aside from that, I agree that changing Configure is starting to look
> like the cleanest solution.

Unfortunately there are a few hurdles to that.

Configure does not currently differentiate between variables passed from
the command line and variables provided by the hints/ files.

Upstream has just released 5.12.4 where hints/linux.sh parses the output
of 'gcc -print-search-dirs', therefore getting the multiarch directories
right when gcc supports them.

It happens that the list includes quite a few directories that don't
normally exist, so the check for existing directories is very much used
in the normal upstream code path.

  % gcc -print-search-dirs | grep libraries | \
    cut -f2- -d= | tr ':' '\n' | grep -v 'gcc' | sed -e 's:/$::'
  /lib/x86_64-linux-gnu/4.6.1
  /lib
  /usr/lib/x86_64-linux-gnu/4.6.1
  /usr/lib
  /usr/lib/x86_64-linux-gnu/x86_64-linux-gnu/4.6.1
  /usr/lib/x86_64-linux-gnu

Our use case (forcing a missing directory into libpth) is exotic enough
that I have a hard time (and, frankly, a lack of motivation) coming up
with an upstreamable way to implement it.

That means the gcc-4.6 build dependency option is looking better again.
However, I just learned sparc still has gcc 4.4 as the default compiler.
So we'd be down to arch specific dependencies again, at least temporarily
(see http://lists.debian.org/debian-sparc/2011/06/msg00012.html ), or
pull in an extra compiler version on sparc just for this.

It wouldn't be too bad IMO to have
 Build-Depends: gcc-4.6 (>= 4.6.0-13) [!sparc], gcc-4.4 (>= 4.4.6-4) [sparc]
assuming there aren't other special cases.  I suppose we should go for it
and do the fine tuning afterwards.
-- 
Niko Tyni   ntyni at debian.org