> Also, this would rely on "debian/rules clean" completely reversing > the effect of a build, and I can tell you right now, this was not > true of *any* package I have adopted
It's required to do so :-) And if you (like me) build sources during each round of the development cycle, you actually rely on it to completely reverse the effects of 'build', otherwise you have cruft in the source package. But that's rather easy to detect and to fix (IMHO): just look through the .diff.gz... Anyway, the clean-after-build idea has died, we have a better approach now (dpkg-genbuilddeps, which inserts the Build-* fields into the .dsc before signing.) > But I'm not entirely sure that point 2 is a major issue. Look at > binary packages: we automatically generate only the *easy* > dependencies (shared libs and the like). If a program execs some > other program, we leave it up to the package maintainer to notice > and declare the dependency. Most of our users are more concerned > with binary package dependencies -- why should we spend so much > extra work on getting the source dependencies perfect when the > binary dependencies are still so often at the mercy of the > maintainer? Because auto-generating parts of src-deps saves a lot of work and errors for the maintainers, just like auto-generating parts of binary deps does... > Here's something no one has mentioned: why not extend the shlibs > format to include the necessary -dev package? Seems to me that that > would be a lot easier and quicker and would do *most* of what we > need in most cases. And wouldn't require major (and backwards- > incompatible) changes to our whole package generation mechanism). That's more or less what I suggested... Ok, I was talking about a new file "devdeps", but that's technically not much different from extending the syntax of shlibdeps. Roman
