> No, the problem is where to find the information after the source is > unpacked. And you gave the answer: In the dsc file. It should be > copied to the target directory (the parent directory of the package > tree) by dpkg-source -x just as the orig.tar.gz file is. [...] > I think my idea above is better, because it leaves the critical > information into the place where it belongs. Are there any > disadvantages with my suggestion?
Hmm... maybe my personal aversion against random files cluttering up my dirs? :-) I also usually use dpkg-source -sn -x to unpack sources, because I hate that .orig.tar.gz lying around... so one more file? But a more rational argument: If you rely on the .dsc being in the parent dir of the build tree, that tree isn't really self-contained anymore, which it currently is. > For simple cases, there is no magic. But if the dependencies are > complex, for example because they nivolve virtual packages or > complex version dependencies, the correct actions to perfom are > better figured out by human with the help of apt. Duplicating all > the logic in yet another tool seems to be superflous(sp?) to me. There seems to be some misunderstanding here. I didn't want to reprogram apt with all the dependency solving etc. dpkg-check-srcdeps will only print packages that are mentioned in the src-deps, and that list is intended is input list for apt. (I and U treated equally -- they're installed) The actual installation is still done by apt, including installing more pkgs if dependencies requires this etc. Versioned dependencies aren't that complex -- dpkg-check-srcdep only has to compare the installed version with the wanted version. Virtual pkgs aren't worse, too: If an installed package provides the virtual pkg, this can be easily detected and no output for this src-dep is generated. Otherwise, the virtual name (with I tag) will be printed. (apt will tell you what alternatives exist, and sbuild is able to parse that list and choose a pkg from it.) The only thing where dpkg-check-srcdeps is going a bit deeper is alternatives handling: - if at least one alternative is installed in a matching version, nothing is printed - if at least one alternative is installed, but the version is too old, the first such pkg will be printed with U tag - if none of the alternatives is installed, the first one will be printed with I tag But the code for all this already exists in sbuild, I just have to cut&paste it to a new script. > I was just agreeing with you. Ok :-) Roman