Re: 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_cross-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…
Reply to: