Control: severity -1 important On Thu, Jan 21, 2016 at 08:07:27AM +0100, Johannes Schauer wrote: > Severity: serious > Justification: Policy 7.5 I am downgrading not because I disagree, but because that idiocy isn't 'new', its here since day one (I assume as build-dep is very seldom changed… basically only on bugreport from you ;) ) which shows how serious that is in the grand scheme of things, but lets start at the top: > It seems automake (= 1:1.14.1-4) provides automake-1.14 while automake > (= 1:1.15-3) provides automake-1.15. It might be that somehow apt sees > that "automake" provides automake-1.14 but does not store which version > of "automake" provides it apt does store this information and the apt resolver 'happily' makes use of that information… > and just either installs the newest one in the > "apt-get build-dep" case or … its just that build-dep has its own 'resolver' for the first level of dependencies (the Build-Depends in the Sources files) which is very suboptimal for various reasons even if it were on feature-parity with the rest of apt - but it of course isn't even that. I am actually working for a few days now on retiring this build-dep resolver – basically how sbuild and co do it too: create a dummy package and call install on it, but that is easier said than done. It slowly begins to work through and I stumbled yesterday over a grossly simplified instance of this bug: On a amd64 machine, install foo:armel (v1 M-A:no) have a foo:armel (v2 M-A:foreign) in your sources and run build-dep foo-depender (Build-Depends: foo). build-dep happily believes it doesn't need to upgrade foo (it helps understanding why that is the same bug knowing that multi-arch is implemented with [versioned] provides in apt). [One of our tests was actually implementing this by accident and I lost a few hours to debugging until I realized that the apt resolver is actually right and the test (and build-dep) wrong…] So, I think we will be able to close this bug (and plenty of [unreported] others) relatively soon, but that patch isn't going to be easily backportable to jessie. If someone feels like needing this I am happy to help, but I will not invest time on it myself… (after all, the result of that backport would just be an error until the next paragraph is resolved) > Ideally, apt should see that there are different versions of the same > package with the same pin value but different provides and pick the one > that satisfies the dependency even if it's of a lower version. After > all, both packages are part of the same suite. Though with apt's > behaviour of selecting only the highest version as the candidate I can > see why this will not be happening and maybe instead automake should Ideally, yes. We have this problem with arch:all packages and arch:any packages having =-depends on them already, so eventually I want to work on this, but the current architecture of the resolver (parts) do not make that a very easy task and its hardly the only thing I want to work on… > change how they do their virtual packages. But then again, on what > grounds should automake change their provides? Only because of an apt > limitation? As far as I can see they are policy compliant and other Debian 'frequently' changes packages to workaround bugs/limitations in apt either because an upgrade is unfeasible (dist-upgrades) or because nobody sits down and actually works on the problem in apt. The same is done for many other "too big to fail" projects. So the ground is simply reality. You have the moral high ground perhaps as "that should work" – but as apt is a Debian native package it itself has the even higher moral ground of "why is nobody working on me(=apt) then?". We are happy to help out with specific answers if a package maintainer can't make it work by itself (if they pick the 'easy' way out), but please understand that we can't pro-actively check all source packages and even if we are told the source package we tend to lack the knowledge in this area to provide help without the maintainer describing the intend behind all this first. [ btw: If we go all policy on this for a second, I wonder if §3.6 isn't prohibiting this usage without discussion given that this isn't a private virtual package, but a public interface… /nitpick ] > resolvers like dose3 or aspcud will happily find a solution. I hope so! Otherwise I would seriously question what researchers have done in the last decade (we are actually getting close to two now)… ;) Of course, they aren't perfect either or someone surely had put in the effort of making them the default… Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature