Niko Tyni wrote: > On Mon, Jun 20, 2011 at 04:05:49PM -0500, Jonathan Nieder wrote:
>> unpack new perl-base >> unpack multiarchified libc >> configure multiarchified libc >> configure new perl-base > > I wonder if there's a danger of an unrelated future change (in either > perl or eglibc) bumping the version constraint and causing problems. > However, I don't think we should worry about that overmuch at this point. Oh. Yes, that's very likely --- see Bug#625522 (memcpy is attached to the new GLIBC_2.14 version node in upstream glibc on amd64). :/ But I agree, it seems best to cross that bridge when we get there (perhaps by asking perl to use memcpy@GLIBC_2.2.5 explicitly on amd64). > http://anonscm.debian.org/viewvc/pkg-glibc?view=revision&revision=4674 > > I see this isn't quite the intended use of the multiarch-support package. > Would it really work? There's no guarantee that multiarch-support > pulls in a recent enough libc6, so we'd just be relying on the general > availability of multiarch-support itself. You're right --- there's no reason for that to work. Hm. Ah, here we go. Based on how Configure computes libpth, what I should have said is gcc-4.6 (>= 4.6.0-12). > I think arch:all packages may > well be available before the corresponding arch:any packages get built > and uploaded. Sorry for the nonsense. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
