[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dpkg-checkbuilddeps to generate a frontend friendly package list

> Hi,


> 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:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=214566

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
> cleanup.


> 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 
effort' approach.

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>

Reply to: