On Thu, 2013-04-18 at 12:05:40 +0200, Marc Haber wrote: > On Tue, Jan 08, 2013 at 04:34:08AM +0100, Guillem Jover wrote: > > Well that patch has not been in a mergeable state since then, so > > consequently it did not get applied. > > It would have been nice to have a comment stating this to the bug > report to avoid more time to be wasted.
This was pretty clear from the discussion started around that particular patch on the debian-dpkg mailing list. > > The root issue here is that to perform the task the bug reporter is > > requesting from dpkg-checkbuilddeps, the program would need access to > > whatever frontend database is being used, something dpkg-dev cannot > > know or assume. > > Why? I'm not sure what part the why is referring to, so: The reason to either need access to the repository information is so that the dependecies could be checked against the availability of packages/versions to produce a correct list of packages to install, possibly with version specifiers, so that the correct version, when multiple are available would get requested, or the correct alternative when one is not satisfiable (the OR depedencies problem Frank, a maintainer at the time, mentioned some time ago). Having a Build-Depends of “perl (>= 5.16.0) | libfoo-perl” with perl=5.14.2 installed and getting just perl as output is pretty much unsatisfactory and confusing, given that perl is already there, and I'm not looking forward to such kind of user confusion or derived bug reports. The reason why dpkg-dev cannot currently know or assume a specific frontend is because (as implemented in the patch) doing so would be a layer violation, making the code depend on something up the stack, and hardcoding a specific frontend, which are unacceptable, also stated on the mailing list. The path for a solution should come after wheezy, as I stated on the part trimmed from my previous mail to this bug report. > > Blindly outputting version-less package entries that might or might > > not be able to satisfy the dependencies anyway, seems very > > suboptimal, and currently one is best served by one of the frontend > > aware alternatives. > > Which ones? For example mk-build-deps, pbuilder-satisfydepends, sbuild or embuilddeps, as stated elsewhere. Regards, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
