On 2012-10-17 23:57, Jakub Wilk wrote:
> I'd tend to agree that M-A:foreign for -dbg packages is always wrong.
>
> * Niels Thykier <ni...@thykier.net>, 2012-09-03, 13:49:
>> For a library, I see the problem the "-dbg" has symbols for a "M-A:
>> same" package (e.g. a library). But for some package that is "M-A:
>> foreign", I don't see why the related "-dbg" package couldn't be "M-A:
>> foreign".
>> Sure it might be "weird", but I don't immediately see how it would
>> break anything.
>
> If there's a -dbg package for a MA:foreign package, then something is
> already broken. Imagine a situation like this:
>
> Package: foo
> Multi-Arch: foreign
>
> Package: foo-dbg
> Depends: foo (= ${binary:Version})
>
> Now I can co-install foo-dbg:amd64 and foo:i386, despite the fact that
> foo-dbg is useless in such setup.
>
> (I'm afraid it's a corner-case of multi-arch that hasn't been
> well-thought yet...)
>
Hah, in that case, foo should be "Multi-Arch: allowed". In this case
rdeps can use "foo:any" to use the foreign dependency and the debug
package could use "foo" (implying the "Multi-Arch: same" relation)...
I know, it is a poor solution as it kills a major advantage of M-A
foreign as now a bunch of rdeps needs to append ":any" due to a debug
package. But the situation did remind me of Steve's favourite M-A:
allowed example python (and I think this was how he used M-A:allowed).
Anyhow, it is unfortunate that this mistake is possible, at least the
right foo-dbg is installable for all variants of foo.
~Niels
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
