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