Hi, Policy says:
> Run-time support programs that use the shared library but are not > required for the library to function or files used by the shared > library that can be used by any version of the shared library > package should instead be put in a separate package. This package > might typically be named libraryname-tools; In 2008, Russ Allbery wrote: > Fabian Greffrath <greffr...@leat.rub.de> writes: >> However, in practice the -utils suffix for the discussed type of >> packages seems to be much more widely used than the -tools suffix that >> is suggested by policy 8.2. [...] >> I propose a change in the wording of the last sentence, maybe to something >> like this: >> >> This package might typically be named libraryname-utils or (at your >> option) libraryname-tools; [...] > I suppose we could, but does it really matter? We already changed it from > -runtime to -tools because almost no one uses -runtime, but -tools and > -utils are close enough that I'm not sure there's any real difference. For what it's worth, I agree that it doesn't seem likely to matter. The wording "might typically be" is already very tentative, and I can't imagine it causing harm when someone uses the advice to name their new libfoo-tools package. So while I like the empiricism behind it, I don't think this change is needed or warranted. Would you mind if the bug were closed? Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
