Explicit arch qualifiers in “Depends” field
 

Hi,

A small set of packages would benefit from explicit arch qualifiers in *-Depends.
Indeed, a cross-compiler, for instance, is meant to run on a certain (build) architecture
and use libs from the foreign (host) architecture.
This isn't actually possible in Debian, since the MultiArch spec only allows the “:any” qualifier,
and dpkg actually reject anything different from “any”.

So, I've played a bit with dpkg and apt.
It turns out dpkg handles cross-arch dependencies perfectly, it only rejects anything else than “any”.
Disabling this test does the trick.

Apt uses implicit “Provides” to satisfy “:any” dependencies and treats the arch qualifier
as part of the package name. One obvious solution would be to add an implicit “Provides”
to each package to satisfy “$package:$arch”. But considering the enormous number of implicit provides
this would add (at least one per “M-A: same” package), I think it's a very bad idea.
Another solution would be to add effective cross-arch dependencies.
It turns out to be fairly easy, but a proper patch would need a bit more work,
and this might have a number of subtle implications I haven't thought of.

Here are patches for dpkg and apt. They need reviewing, and the apt one could probably be cleaned up
a bit. Anyway, there are a few questions left:

1. When parsing the *-Depends fields, should dpkg check whether the arch is known?
I think it doesn't matter, as a package with a dependency qualified with an unknown arch
would be uninstallable anyway.
2. Should a package be able to depend on a package regardless of its M-A field?
I think it only makes sense for a package to depend on a “M-A: same” or “M-A: allowed” package,
“M-A: foreign” packages providing arch-independent interfaces, and M-A unaware packages
probably being unwanted.
On the other hand, explicitly disallowing other packages would probably be unnecessary work.
3. Have I overlooked something?


Regards,
Thibaut.

Explicit arch qualifiers in “Depends” field
 

On Wed, Apr 18, 2012 at 20:50, Thibaut Girka <thib@sitedethib.com> wrote:
> A small set of packages would benefit from explicit arch qualifiers in *-Depends.

About what do we talk here?
Your apt patch clearly is only about dependencies in binary packages,
while "*-Depends" matches only build-dependencies which supports also
your mentioning of a cross-compiler as it hasn't foreign dependencies,
but foreign build-dependencies…
(But it might also be that i don't get the cross-compiler example)


> Apt uses implicit “Provides” to satisfy “:any” dependencies and treats the arch qualifier
> as part of the package name. One obvious solution would be to add an implicit “Provides”
> to each package to satisfy “$package:$arch”. But considering the enormous number of implicit provides
> this would add (at least one per “M-A: same” package), I think it's a very bad idea.

The problem we had to deal with is that at the time we create the
dependencies we have to know to which package(:arch) we need to link to
before we know which packages will be available at all (and in which
architecture). Obviously, that is a bit hard to know if :any is used,
so we us the provides trickery with a pkg:any package provided
by all M-A:allowed pkg packages. This way we have again only one
package we can link to.

If there is an architecture explicitly mentioned we don't need that as we
already know which package we have to link to, so yes, doing implicit
provides would be a very bad idea (nor would it work).


> Another solution would be to add effective cross-arch dependencies.
> It turns out to be fairly easy, but a proper patch would need a bit more work,
> and this might have a number of subtle implications I haven't thought of.

It looks about right - it should really not be hard given that this is
actually the easy problem (and i thought this sort of works already -
at least it did sometime in the process -- or i just mix that up with
Build-Depends now in which this is already supported as it actually harder
to implement to not support it as it is done way later, so we have a
complete cache and we know which packages are available…).

But that doesn't help much. Most tools do not support non-self-containing
dependencies which needs to be fixed first before we can thing about doing
these additions on dpkg/APT level. It doesn't help much if we can install
such packages if they are neither build nor migrate to testing.

And these problems effect us today even without MultiArch.
(e.g. arch:all packages depending on arch:any which are not available
for all architectures. the arch:all package will never migrate to
testing even through it is available for at least some archs
(or specifically: not available for i386), so you either have to hack
with [arch] or make it any, both is bad…)

See also [0] and [1] in the MultiArch spec which talk about this and
a related issue.


Best regards

David Kalnischkies

[0] https://wiki.ubuntu.com/MultiarchSpec#Allow_official_packages_to_have_cros s-architecture_deps
[1] https://wiki.ubuntu.com/MultiarchSpec#Architecture-independent_packages_that_can_only_be_generated_on _one_architecture

P.S.: Sry for not answering on IRC earlier…


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAAZ6_fBiRA05gzOuc-B0D9Yno3sCkVygV3nqMh=UzeX-n6ykMw@mail.gmail.com">http://lists.debian.org/CAAZ6_fBiRA05gzOuc-B0D9Yno3sCkVygV3nqMh=UzeX-n6ykMw@mail.gmail.com

Explicit arch qualifiers in “Depends” field
 

On Thu, Apr 19, 2012 at 02:25:19PM +0200, David Kalnischkies wrote:
> On Wed, Apr 18, 2012 at 20:50, Thibaut Girka <thib@sitedethib.com> wrote:
> > A small set of packages would benefit from explicit arch qualifiers in *-Depends.
>
> About what do we talk here?
> Your apt patch clearly is only about dependencies in binary packages,
> while "*-Depends" matches only build-dependencies which supports also
> your mentioning of a cross-compiler as it hasn't foreign dependencies,
> but foreign build-dependencies…

“*-Depends” is misleading, my bad.
We are indeed talking about binary packages fields, that is, “Depends”,
“Pre-Depends”, etc.

A cross compiler *has* foreign dependencies *and* foreign build-deps.
I think the case of foreign build-deps has already been addressed,
but I must admit I haven't checked.

> (But it might also be that i don't get the cross-compiler example)

(It is about the cross-compiler example)

<snip>

> But that doesn't help much. Most tools do not support non-self-containing
> dependencies which needs to be fixed first before we can thing about doing
> these additions on dpkg/APT level. It doesn't help much if we can install
> such packages if they are neither build nor migrate to testing.

While it would be ideal to have such packages supported by the archive,
I think it makes sense to support cross-arch deps regardless.
Indeed, back at the cross-compiler example: emdebian currently provides
cross-toolchain packages[2] in a separate repository.
Such packages depend on “converted” foreign package ones using “dpkg-cross”,
which basically changes the “Architecture” field to “all” and move files around
for MA-unaware packages.
It would be cleaner for those packages to have cross-architecture deps instead.

> And these problems effect us today even without MultiArch.
> (e.g. arch:all packages depending on arch:any which are not available
> for all architectures. the arch:all package will never migrate to
> testing even through it is available for at least some archs
> (or specifically: not available for i386), so you either have to hack
> with [arch] or make it any, both is bad…)
>
> See also [0] and [1] in the MultiArch spec which talk about this and
> a related issue.

As stated above, while the official archive may not be ready for such packages yet,
I think it makes sense to allow third-party ones to use cross-dependencies in the meantime.

> [0] https://wiki.ubuntu.com/MultiarchSpec#Allow_official_packages_to_have_cros s-architecture_deps
> [1] https://wiki.ubuntu.com/MultiarchSpec#Architecture-independent_packages_that_can_only_be_generated_on _one_architecture
[2] http://www.emdebian.org/crosstools.html

> P.S.: Sry for not answering on IRC earlier…
No problem.

Regards,
Thibaut.

Explicit arch qualifiers in “Depends” field
 

Hi Thibaut,

On Wed, Apr 18, 2012 at 08:50:24PM +0200, Thibaut Girka wrote:

> A small set of packages would benefit from explicit arch qualifiers in
> *-Depends. Indeed, a cross-compiler, for instance, is meant to run on a
> certain (build) architecture and use libs from the foreign (host)
> architecture. This isn't actually possible in Debian, since the MultiArch
> spec only allows the “:any” qualifier, and dpkg actually reject anything
> different from “any”.

Yes, this is disallowed in the current multiarch specification, but is an
area for future expansion in connection with the building of cross-compilers
and similar cases.

At last DebConf, the release team and ftp team agreed that this is a
reasonable thing to support, though we don't yet have a roadmap for how to
get there.

> 2. Should a package be able to depend on a package regardless of its M-A
> field? I think it only makes sense for a package to depend on a
> “M-A: same” or “M-A: allowed” package, “M-A: foreign” packages
> providing arch-independent interfaces, and M-A unaware packages
> probably being unwanted. On the other hand, explicitly disallowing
> other packages would probably be unnecessary work.

If we're going to support explicit cross-arch dependencies, I believe they
should be allowed regardless of the M-A field on the target package.
Certainly, there's no reason to permit it for M-A: allowed packages but not
for M-A: none packages, since an M-A: allowed package is always treated as
either M-A: foreign or M-A: none. And even for an M-A: foreign package,
there might be special circumstances where you want to specify the
architecture, such as when creating a metapackage of some kind.

Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org