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