Bug#486453: Policy 8.2 suggests libraryname-tools, but not libraryname-utils
> 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 <firstname.lastname@example.org> 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?