Bug#630399: perl: multiarch libc and partial upgrades

[Niko Tyni]

On Fri, Jul 01, 2011 at 02:28:12PM -0500, Jonathan Nieder wrote:
> Niko Tyni wrote:

> > Maybe go back to specifying plibpth manually to Configure for a while
> > (overriding the upstream change of parsing 'gcc -print-search-dirs'),
> > and Build-Depend on 
> >  gcc-4.6 (>= 4.6.0-13) | gcc-4.4 (>= 4.4.6-4)
> > which guarantees that /usr/lib/<triplet> exists regardless of which gcc
> > is actually used.

Unfortunately it's even worse: the default gcc on hppa is 4.5.
That makes

 gcc-4.6 (>= 4.6.0-13) | gcc-4.5 (>= 4.5.3-3) | gcc-4.4 (>= 4.4.6-4)

Perhaps we should even include gcc (>> 4:4.7) to be future proof.

> Makes sense.  That could be
> 
>   gcc-4.6 (>= 4.6.0-13) | gcc (<< 4:4.5), gcc (>> 4:4.6) | gcc-4.4 (>= 4.4.6-4)
>
> to make sure the /usr/bin/gcc symlink points in the right place,

Uh, I had to read that twice to get the idea. I'm not going to try
to expand it to three gcc versions :)

Anyway, if we go back to the passing /usr/lib/<triplet> as a Configure
argument, I don't think it matters whether /usr/bin/gcc looks there or
not. In that case, the above list of gcc versions is there just to make
sure *some package* (and preferably an already installed one) has put
a file in /usr/lib/<triplet>.

> except I have a vague fear that autobuilders might simplify it to
>
>   gcc-4.6 (>= 4.6.0-13), gcc (>> 4:4.6)

(as an aside, I *think* it should work: the first alternative always
 gets picked unless the second alternative is already satisfied by an
 installed package. But I've been bitten by alternative b-d resolution
 enough not to bet very much on that.)
-- 
Niko Tyni   ntyni at debian.org