From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Agreeing on some "rules" for packaging. Date: Thu, 29 Aug 2013 00:42:31 +0200 Message-ID: <87r4dd4eug.fsf@gnu.org> References: <521D1E38.9090604@gmail.com> <87sixuc71q.fsf@gnu.org> <521E423C.7010107@gmail.com> <20130828205616.GA12493@debian> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58488) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VEoWb-00064r-GD for guix-devel@gnu.org; Wed, 28 Aug 2013 18:47:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VEoWV-0004ZO-9K for guix-devel@gnu.org; Wed, 28 Aug 2013 18:47:41 -0400 Received: from hera.aquilenet.fr ([141.255.128.1]:51770) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VEoWU-0004ZG-Ux for guix-devel@gnu.org; Wed, 28 Aug 2013 18:47:35 -0400 In-Reply-To: <20130828205616.GA12493@debian> (Andreas Enge's message of "Wed, 28 Aug 2013 22:56:16 +0200") List-Id: 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: Andreas Enge Cc: guix-devel@gnu.org Andreas Enge skribis: > Please find attached a patch with proposed conventions for package names, > including in the presence of packages for several version numbers > (such as python itself), and for python modules. Looks like it already went in. :-) That seems like a very good start. I agree with the proposed rules, so I just have a cosmetic comments: > diff --git a/doc/guix.texi b/doc/guix.texi > index dfffdbf..ca2871b 100644 > --- a/doc/guix.texi > +++ b/doc/guix.texi > @@ -1631,7 +1631,10 @@ needed is to review and apply the patch. >=20=20 >=20=20 > @menu > -* Software Freedom:: What may go into the distri= bution. > +* Software Freedom:: What may go into the distribution. > +* Package Naming:: What's in a name? > +* Version Numbers:: When the name is not enough. > +* Python Modules:: Taming the snake. > @end menu I would perhaps move =E2=80=9CPython Modules=E2=80=9D into a =E2=80=9CSpeci= fic Packages=E2=80=9D subsection (or something like that), where we might eventually have =E2=80=9CPerl Packages=E2=80=9D as well. WDYT? > +@node Package Naming > +@subsection Package Naming > + > +A package has actually two names associated to it: s/to it/with it/ > +First, there is the name of the @emph{Scheme variable}, the one following > +@code{define-public}. By this name, the package can be made known in the > +Scheme code, for instance as input to another package. > +Second, there is the string in the @code{name} field of a package defini= tion. > +This name is used by the package manager. s/package manager/commands such as @command{guix package} and @command{guix= build}/ > +Both are usually the same and correspond to the lowercase conversion of = the > +project name chosen by upstream. For instance, the GNUnet project is pac= kaged s/by upstream/upstream/ > +as @code{gnunet}. We do not add @code{lib} prefixes for library packages, > +unless these are already part of the official project name. > +But see @ref{Python Modules} for special rules concerning modules for s/But see @ref{Python Modules}/@xref{Python Modules},/ (info "(texinfo) @xref") > +@node Version Numbers > +@subsection Version Numbers > + > +We usually package only the latest version of a given free software > +project. But sometimes, for instance for incompatible library versions, > +two (or more) versions of the same package are needed. These require dif= ferent > +Scheme variable names. We use the name as defined in @ref {Package Namin= g} s/defined in @ref {Package Naming}/previously defined (@pxref{Package Namin= g})/ > +for the most recent version; previous versions use the same name, suffix= ed > +by @code{-} and the smallest prefix of the version number that may > +distinguish the two versions. > + > +The name inside the package definition is the same for all versions of a > +package and does not contain any version number. > + > +For instance, the versions 2.24.20 and 3.9.12 of GTK+ may be packaged as= follows: > +@example > +(define-public gtk+ > + (package > + (name "gtk+") > + (version "3.9.12") > + ...)) > +(define-public gtk+-2 > + (package > + (name "gtk+") > + (version "2.24.20") > + ...)) > +@end example > +If we also wanted GTK+ 3.8.2, this would be packaged as > +@example > +(define-public gtk+-3.8 > + (package > + (name "gtk+") > + (version "3.8.2") > + ...)) > +@end example Add linebreaks around @example, possibly with @noindent before the lonely lines. > +@node Python Modules > +@subsection Python Modules > + > +We currently package Python 2 and Python 3, under the Scheme variable na= mes > +@code{python-2} and @code{python} as explained in @ref{Version Numbers}. > +To avoid confusion and naming clashes with other programming languages, = it > +seems desirable that the name of a package for a Python module contains > +the word @code{python}. > +Some modules are compatible with only one version of Python, others with= both. Add linebreak before =E2=80=9CSome modules=E2=80=9D. Also, please leave two spaces after an end-of-sentence period. Thanks, Ludo=E2=80=99.