On Thu, May 09, 2013 at 04:59:28PM +0100, Wookey wrote:
> +++ Goswin von Brederlow [2013-05-09 11:39 +0200]:
> > On Thu, May 09, 2013 at 08:43:22AM +0200, Niels Thykier wrote:
> > > On 2013-05-09 07:56, Paul Wise wrote:
> > > > On Thu, May 9, 2013 at 1:08 PM, Andreas Beckmann wrote:
> > > >
> > > >> I just noticed that we have the first amd64 package in the archive that
> > > >> has dependencies on :i386 qualified libraries:
> > > >>
> > > >> Package: teamspeak-client
> >
> > A Depends like in this case is never right since it mixes biarch
> > (libc6-i386) packages with multiarch (libfoo:i386).
>
> This does seem wrong, especially in this case. I can't think of a case
> where it makes sense offhand, but there might be one.
It should be libc6:i386, libfoo:i386 at least.
> > I would say that a foreign dependency on a library is never right.
>
> That's too strong. It can make sense for cross-tools, or maybe
> emulators, which genuinely need a foreign-arch library to operate. But
> I'm not aware of other sensible usages.
Right. cross-tools are probably the exception there. Forgot about them
for a minute.
> > If
> > the source compiles binaries for the foreign arch then the package
> > should be build on the foreign arch directly. Period.
>
> Apart from the above exceptions, I agree.
>
> We haven't yet formulated any policy on what is/isn't going to be
> allowed/deemed sensible.
>
> > Also, iirc, the use of foreign dependencies is only supposed to be on
> > packages with Multi-Arch: allowed.
>
> I don't think that's relevant/correct. A foreign-arch dep is
> appropriate when the binary is linked against/uses said library, and a
> same-arch libfoo-arch-cross isn't used instead. Said library could be a
> perfectly normal M-A:same package.
>
> I guess it's time to have a think about this stuff and write down some
> guidelines/policy.
>
> Wookey
Should that include binaries linked against libraries? Imho any
foreign arch binary or library should come from a foreign arch
package. So even for cross-tools if they need a foreign binary or
library they should depend on the foreign package containing them.
[And how will they run the foreign binary? seems like the foreign
binaries case shouldn't happen at all.]
That should only leave the "uses foreign library" case. Like a gcc
cross-compiler uses the foreign libgcc. The gcc cross-compiler itself
is not linked against the foreign libgcc though.
But that destroys the idea of DAK catching it. I don't see how
teamspeak-client depending on libfoo:i386 would be cought but
i486-linux-gnu-gcc depending on libfoo:i386 would pass. Unless we add
a specific tag for cross-tools to excempt them from the check.
Looks like we have to keep catching those bugs by hand.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130513102146.GD8366@frosties
