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 <[email protected]> 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
