Re: Thoughts about src-dep implementation
> 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
Reply to: