Re: dpkg-checkbuilddeps to generate a frontend friendly package list
> sorry to not have responded earlier.
> On Fri, 04 Dec 2009, George Danchev wrote:
> > 1) Would you accept patches like that, based on AptPkg, i.e. is it too
> > intrusive for you? I can see your reasons if you prefer to avoid the
> > extra dependency on libapt-pkg-perl.
> AptPkg is really a no-go for me.
> I don't see why it's so important to verify that we have one available
> version to satisfy the build-dependency if we're going to fail anyway.
It is important because it will handle the ultimate use-case. I don't feel
that blindly downloading build-depends (calculated as best-effort), installing
them, and finding out that they are not actually satisfied at some later point
is an ultimate solution. Therefore, I tried to catch these as early as
possible. People might be interested just in build-depends satisfaction tests,
but downloading b-deps and initiating build). Since we are trying to feed a
frontend, I tried to explore some of frontend's features (package/versions
availability and comparisons). I don't want to add unneeded build-dependency
to dpkg-dev (actually it could be avoided, until it is actually needed via
run-time test), just for the sake of it, and I guess it might not be entirely
obvious... c'est la vie.
Let me rehash it once again: I'm actually trying to compare (or relate)
package/versions build-dependencies from debian/control of some random package
which eventually never entered the debian archive (no archive meta data
available yet, hence apt-get build-dep won't work in that case) to the
packages really available in the debian archive. Real use cases: introducing
new packages or packages with changed build-depends or checking sponsoree
packages eventually dragged from ubuntu or whatever unofficial repository, where
build-depends might have been actually satisfied for whatever reasons).
> There are definitely some improvements to do in dpkg-checkbuilddeps
> though. Producing that "frontend-frienly" list is certainly
> useful as is introducing a new option to have a machine readable output:
Sure. If we want to feed other apps to process such a list, then I thing the
list should be as sane as possible.
> I'm certainly interested in patches for those issues. Please work on
> the master branch, there have been some recent changes due to the API
> Also please use the various existing modules when possible (for example
> Dpkg::Version for version comparison).
If we ditch the package version availability and comparisons (processing
debian/control information vs. available packages/versions found in archive),
then there is no use to engage neither Dpkg::Version not AptPkg modules, we
just print a best-effort package name list to the frontend so hope for the
best. That is not the case I'm trying to solve.
> > 3) Rewrite that with calls to `apt-cache policy' (to get available
> > package versions) and `dpkg --compare-versions' (for version
> > comparisons), which is not a sign of great engineering ;-)
> Hell no.
Sure, that was just some salt ;-)
> > 4) Leave that to the Almighty sbuild tool?
> That's the current situation, no?
Actually I didn't verified whether sbuild is actually smarter than the 'best
I'm fine if most of the people think I'm asking for too much from dpkg-dev,
hence separating such a tool into another package is also an option. However,
it would be sad if that only lives on my disk.
pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu>