Norman Ramsey <[EMAIL PROTECTED]> writes: > I have the highest respect for Russ, and he certainly knows more than I > do. It might be good for this clarification to make it into the first > sentence in Section 3.5 of the policy manual. I think Section 7.2 is > already sufficiently clear, but a forward pointer from 3.5 might be in > order.
Policy is definitely not crystal clear in this area; it's fairly ambiguous on exactly what the boundaries of "required to work correctly" and "significant amounts of functionality" are. There probably isn't any absolute metric. To some extent, it's always going to be a judgement call. You can find obvious examples: devscripts shouldn't depend on Subversion just because one binary (debcommit) can't commit changes to a Subversion without it. But where to draw the line between things like that and obvious requirements is hard. There are a *lot* of packages that come with several binaries, some of which require other packages and some of which don't, and what one views as the "primary purpose" varies a lot. As someone who personally maintains a ton of packages that use Autoconf and not Automake, I find running Autoconf without Automake very natural and autoreconf is a very new interface. You'll probably find that opinion common among people who, like myself, have been using Autoconf from the 1.x days. People who start with the autotools fresh in a more recent era will probably have a different take on it. In this particular case, there's also the problem that there's often no obviously best version of Automake to depend on given that there have frequently been multiple versions in the archive at the same time, although that's a more minor concern. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
