> OK, I've just tried to calculate the build-time dependencies for > debian-policy, and here are some thoughts. > > It's not easy. In fact it's *really* not easy.
If you really want to (more or less) automate it, it's really not easy... But for most packages, src-deps are rather clear. It seems you have choosen one of the more complicated ones :-) > I first tried running strace on the build process, but due to the > presence of a vfork, I missed most of the interesting stuff. > So strace is not a particularly useful way of figuring out > dependencies. [...] I think the only really reliable way to find out which packages are used by a build is with some libtricks-like method. I.e., you install a wrapper lib that tracks all execve() & Co. calls and record the invoked binaries somewhere. Later you pipe that list through uniq and call dpkg -S on every entry. At the end, you sort out build-essential stuff and have the desired list. But such a tool has to be written yet... However, I admit that it could be useful. > Standard packages: dpkg-dev, lynx, make > > Now these should need listing, as they are not marked essential. dpkg-dev and make are build-essential. > But hey! debiandoc-sgml itself depends on sp, so I could optimise > and not list sp. This would, however, be dangerous, as what happened > if the dependencies (maybe not in this example, but elsewhere) > changed? So I'll still list both of these. That's exactly the thought expressed in policy: You should list packages you call binaries of, but not their dependencies. > Firstly, that if we are now demanding build-time dependencies, we > are asking maintainers to do a *lot* of work. (This took me about 2 > hours, maybe a little bit more.) We ought to think of a better way > of performing this task if we want maintainers to take it seriously. See above: I guess you've picked a complicated case, and second such a tool like mentioned above would be useful. > Thirdly, of the packages listed, dpkg-dev and make are needed by > every package build, so should not be needed to be listed. I wonder > whether we can have a tag "Build-Essential: yes" for a small number > of packages which are assumed to be present on any builder, and that > do not need to be listed? (Proposed) policy says that such build-essential packages exist and defines them indirectly. (See other discussions here on the list.) > Finally, a small point. It may be worth stating that if a package is > required to satisfy an (install-time) dependency of a listed > dependency, then it does not need to be listed itself. Although, > having said this, I think this is obvious. Expressed in the wording of the proposal already... Roman
