Bug#683786: apt-get cross build dependency resolution of arch:all, m-a:none packages
Hi,
On Mon, Aug 06, 2012 at 01:05:13AM +0200, David Kalnischkies wrote:
> 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!
I guess I'm just as interested in making my tool work as you are in
yours ;)
> > (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).
Yes, it's not of importance for me anymore. I just first generate the
list of source packages that can actually be compiled for an
architecture with my tools and feed only those to apt.
> 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…
You are writing a solver?
> 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 …
Those useless dependencies give me multiple headaches - my GSoC project
is bootstrapping Debian and useless dependencies like this just create
so many new cyclic dependency situations for nothing...
> You lost me, I don't understand how this paragraph (speaking about
> implicit dependencies on essential packages) could apply to explicit
> dependencies.
It is not - but nothing else there talks about essential packages.
> 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.
Good, then I will also let dose3 keep on failing for those two packages.
> 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?
You are right. I must've developed too much confidence in my tools and
thereby have overlooked that automake is indeed M-A:foreign.
The error is in dose3 here, which does not (yet, but will tomorrow)
apply multiarch properties to the virtual packages it provides.
> 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).
Yeah somehow I failed to find that option. I'm using it now and started
just another run across all source packages. :)
Thanks again for your quick reply! :D
cheers, josch
Reply to: