Bug#486453: Policy 8.2 suggests libraryname-tools, but not libraryname-utils

[Jonathan Nieder <jrnieder@gmail.com>]

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 <greffrath@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