unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Andreas Enge <andreas@enge.fr>
To: Alex Kost <alezost@gmail.com>
Cc: guix-devel@gnu.org
Subject: Re: Font package naming convention
Date: Fri, 31 Oct 2014 18:58:40 +0100	[thread overview]
Message-ID: <20141031175840.GA16902@debian> (raw)
In-Reply-To: <878ujxdxmj.fsf@gmail.com>

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

  reply	other threads:[~2014-10-31 17:59 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-28  6:53 [PATCH 2/2] gnu: Add 'ttf-liberation' Alex Kost
2014-10-28  8:10 ` Ludovic Courtès
2014-10-29 22:16   ` Andreas Enge
2014-10-30  7:27     ` Alex Kost
2014-10-30  7:56       ` Andreas Enge
2014-10-30 12:52         ` Alex Kost
2014-10-30 13:36           ` Andreas Enge
2014-10-30 18:55             ` Alex Kost
2014-10-30 17:20           ` Font package naming convention Ludovic Courtès
2014-10-30 17:32             ` Andreas Enge
2014-10-30 22:54               ` Ludovic Courtès
2014-10-30 18:55             ` Alex Kost
     [not found]               ` <20141030191743.GB19999@debian.eduroam.u-bordeaux.fr>
2014-10-30 22:02                 ` Alex Kost
2014-10-31 17:58                   ` Andreas Enge [this message]
2014-10-31 18:00                     ` Andreas Enge
2014-10-31 21:30                     ` Ludovic Courtès
2014-11-01  9:52                       ` Andreas Enge
2014-11-02 17:18                         ` Ludovic Courtès
2014-11-02 17:49                           ` Andreas Enge
2014-11-03  8:53                             ` Ludovic Courtès
2014-11-03  9:30                               ` Andreas Enge
2014-11-03 13:36                                 ` Alex Kost
2014-11-03 20:28                                 ` Ludovic Courtès
2014-11-19  9:01                                 ` Ludovic Courtès
2014-11-19 10:22                                   ` Andreas Enge
2014-11-20  7:09                                   ` Alex Kost
2014-11-23 20:13                                     ` [PATCH] gnu: Add 'font-liberation' Alex Kost
2014-11-24 14:12                                       ` Ludovic Courtès
2014-11-01  9:36                     ` Font package naming convention Alex Kost
2014-11-01  9:45                       ` Andreas Enge
2014-11-01 10:55                         ` Alex Kost

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141031175840.GA16902@debian \
    --to=andreas@enge.fr \
    --cc=alezost@gmail.com \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).