Bug#683786: apt-get cross build dependency resolution of arch:all, m-a:none packages
On Sun, Aug 5, 2012 at 9:23 PM, Johannes Schauer <j.schauer@email.de> wrote:
> Out of 18244 source package in Debian Sid, apt-get and dose3 now only
> disagree on 10 remaining packages
Wow. Thanks a lot for this analyze!
> (actually that number is only true
> assuming that apt bug#683917 would also be resolved).
I don't think we will fix that for wheezy as the cost/usage is to low
(we need at least one new string for this - and we have no sane exit
code concept, so you wouldn't get a distinct one. If you need the
functionality I can hack something together for testing, but it sounds
like you already can detect that anyway).
> libcatalyst-actionrole-acl-perl
> obex-data-server
> trueprint
As Julian already said, these look like rc-bugs as only the first option
will be explored by sbuild (for consistency reasons).
APT could certainly do better in these situations, but that it doesn't
make it is okay for now as the fix is a lot of work for a greedy solver.
(We have a big FIXME for this in the build-dep code and I hope to get
this code replaced by reusing our "normal" solver more, so this might
get better in the future, but probably never really solved until we have
a SAT (or its technical superior successor [invented by me] XYZ) solver…)
> qdox
> ----
>
> Was not able to make out what apt-get actually has a problem with.
I don't get it either, but APT seems to chuckle at getting all of
default-{jre{,-headless},jdk} installed which have a lot of provides, so
I guess it is also a "only the second alternative works" problem.
Also, some parts of the dependency tree do not seem to adapted to
multi-arch yet (e.g. libgif4 is M-A: none).
> renattach
> ---------
>
> Build-Depends on exim4 | mail-transport-agent.
>
> Virtual packages like 'mail-transport-agent:armel' can't be removed
The error message is completely bogus, but harmless as it stems
from code reuse - and I will just disabled the printing of it.
(Enabled by the TryInstall change mentioned earlier)
> Dose3 on the other hand just satisfies the mail-transport-agent
> dependency using xmail and is done with it.
The reused code mentioned is used to detect if one package is the
sole provider - as mail-transport-agent is provided by many packages
it obviously doesn't find one (but many) and bails out prompting user
to choose one and install this first. It is intended behavior (or at least
it is that way for a long time now)
Slightly related, I seriously wonder what a package does that it build-deps
on a mail-transport-agent and procmail. I figured it might be tests, but
a testbuild without both works fine …
> Fail with dose3
> ===============
>
> Dose3 cannot satisfy the dependencies of the following source packages
> while apt-get can: bomberclone, freetalk, garden-of-coloured-lights,
> mailsync, worker.
>
>
> bomberclone
> -----------
>
> Build-depends on findutils:armel which clashes with the installed
> package findutils:amd64.
>
> Apt-get chooses to just remove findutils:amd64 and replaces it with
> findutils:armel. The multiarch cross spec doesnt cover this case so it
> is debatable whose behaviour is right.
APT prints a big warning and requires an insane confirmation string
to do this through, so I think both have the correct behavior here.
(assuming that dose3 isn't "talking" with the user on a regular base)
> Maybe the following section of the multiarch spec should apply to the
> cross case as well:
>
>> it is assumed that any undeclared dependencies on Essential packages
>> on the part of multiarch packages is satisfied by the binaries from
>> the native architecture
>
> Therefore, apt-get should not replace findutils:amd64 by findutils:armel
> and dose3 should see the findutils:armel dependency satisfied by
> findutils:amd64.
>
> But this has to be discussed in another place.
You lost me, I don't understand how this paragraph (speaking about
implicit dependencies on essential packages) could apply to explicit
dependencies.
This paragraph just tells us that we don't suddenly need to freak out
about implicit dependencies on essential packages as these are by
definition M-A:foreign. This, even if the difference is small, doesn't make
the package itself M-A:foreign. All it says is that a postinst script of
an armel package can copy files with 'cp' without worrying - the (most
likely) foreign cp will handle it just fine. Even through the package
coreutils isn't M-A:foreign yet.
> freetalk
> garden-of-coloured-lights
> mailsync
> --------
>
> Build-Depends on automake1.11 which is a virtual package provided by
> automake. Apt get wrongly installs the native version of automake
> instead of automake:armel.
The behavior of APT seems to be correct:
automake1.11 is provided by automake which is arch:all and M-A:foreign,
so any - preferable build-arch - satisfies the dependency. Right?
> A bit off-topic
> ===============
>
> Can I somehow force apt-get to satisfy the build dependencies for a
> given source package and not fall back to another? It is really
> bothersome to read:
>
> Picking 'kmod' as source package instead of 'module-init-tools'
Sounds like you want the ' --only-source' flag.
build-dep does a binary to source package mapping by default and only if no
binary package with that name exists uses the name to search for a source
package. The --only-source flag prevents the interpretation of packagenames
as binaries first (I presume the manpage should have a not about this for
build-dep, not just the flag hidden in the long listing of all options).
Best regards
David Kalnischkies
Reply to: