Niko Tyni wrote:
> I'd really like to avoid a situation where a perl binNMU may render
> upgrades from squeeze impossible.
>
> The only broken functionality that we're currently aware of
> (ExtUtils::Embed) is actually in perl-modules.
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?
> I think we could bump the perl-modules dependency on perl (and therefore
> transitively perl-base too) and make libc6 break just perl-modules.
[...]
> Does this make sense to you?
If no one is depending implicitly on perl-base to DTRT with respect to
the library path, yes. That's a big "if", unfortunately.
> 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).
>
> Because that would also make sure there's something in
> /usr/lib/x86_64-linux-gnu (or its equivalent on other architectures)
> regardless of which libc6 version is installed?
Make that gcc-4.6 (>= 4.6.0-13). Reasons:
1) the package ships files under /usr/lib/<triplet>, as you
mentioned (and its versioned dependency libgcc1 includes files
under /lib/<triplet>)
2) it's recent enough for GCC's own search path to be correct,
even in mips/mipsel.
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".
> Thanks for your help on this,
No problem. Sorry for all the nonsense.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
