From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Enge Subject: Re: Font package naming convention Date: Fri, 31 Oct 2014 18:58:40 +0100 Message-ID: <20141031175840.GA16902@debian> References: <87oaswbs72.fsf@gmail.com> <87bnowlimh.fsf@gnu.org> <20141029221647.GA29707@debian> <87d29af24q.fsf@gmail.com> <20141030075640.GB27584@debian> <8738a5g1nh.fsf@gmail.com> <87ioj1sccx.fsf_-_@gnu.org> <87ppd9e6ah.fsf@gmail.com> <20141030191743.GB19999@debian.eduroam.u-bordeaux.fr> <878ujxdxmj.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58880) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XkGTN-0007Fu-SB for guix-devel@gnu.org; Fri, 31 Oct 2014 13:59:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XkGTG-00035R-DG for guix-devel@gnu.org; Fri, 31 Oct 2014 13:58:53 -0400 Received: from mout.kundenserver.de ([212.227.126.187]:53994) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XkGTG-00035B-4P for guix-devel@gnu.org; Fri, 31 Oct 2014 13:58:46 -0400 Content-Disposition: inline In-Reply-To: <878ujxdxmj.fsf@gmail.com> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Alex Kost Cc: guix-devel@gnu.org 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