Re: Font package naming convention

[Andreas Enge <andreas@enge.fr>]

On Fri, Oct 31, 2014 at 01:02:44AM +0300, Alex Kost wrote:
> I suggest this ↑  IIUC it is a common practice in other distributions.

This is absolutely no argument for us! We have quite a few different
practices from other distributions (and some of them are more logical,
I think, like trying to stick to upstream instead of making our life
more difficult).

> Andreas prefers this ↑

I did not say this. I simply pointed out two different "algorithmic" naming
schemes in the sense that there is an algorithm transforming an upstream name
into a package name. Both have strange effects, I think.

> I'm against any strict binding to an upstream name.  Why should we stick
> to a (potentially strange) upstream name if we know better how a package
> should be called?

This is what we have done so far and it is part of the packaging guidelines.
Otherwise there would be absolutely no limit to renaming and bikeshedding.
What if you think that "foo" should be renamed "bar" and I think it should
be renamed "truc"?

If you want to make a suggestion of a naming scheme that others can follow,
please come up with a description of an algorithm as for python modules -
a transformation of an upstream name into a package name.

To be constructive (which is a bit difficult, as I am still not convinced
we should have a special naming scheme for fonts, but admittedly it has
advantages!), here are a few questions that we should answer:

1)
Do we want to have the font format as part of the name?
Not having it would make things easier for packages containing several
formats; a user looking only for special types of fonts would then have to
go through the package descriptions. We could then prepend "font" or "fonts"
to the package name and drop it from inside (or keep it additionally inside,
which would be somewhat strange, but would avoid strange names occurring for
"unifont", for instance).

2)
Do we distinguish between packages containing one font (possibly in several
variants), prepending it with "font-", and packages containing several
fonts, prepending it with "fonts-", or do we go with a common prefix?

3)
If we want to add the font format to the package name, which font formats
do we want to "support"? We need a complete list.

4)
For the sake of argument, assume we decided on ttf and otf in 2).
Then packages containing only ttf could be prepended with "ttf" or "ttf-font"
or something like this, likewise for packages containing only otf.
We could use the "file extension" such as "ttf", or any longer version
such as "true-type-fonts".

What would we do for packages containing exactly both?
None of them?
ttf and others?
otf and others?
ttf, otf and others?
There are several solutions to this.
Notice that if our list of font formats has n entries, we have 2^n-1 possible
combinations. So the longer the list, the less reasonable it seems to prepend
all contained formats.
Notice that such a naming scheme also puts the burden on the packager of
determining the exact list of font formats contained in an upstream package.

I think we need to provide answers to these questions and maybe others I
overlooked.

With the hope that this rather long message may advance the discussion,

Andreas