Re: Agreeing on some "rules" for packaging.

[Ludovic Courtès]

Andreas Enge <address@hidden> 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.
>  
>  
>  @menu
> -* Software Freedom::                         What may go into the 
> distribution.
> +* 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 “Python Modules” into a “Specific Packages”
subsection (or something like that), where we might eventually have
“Perl Packages” as well.  WDYT?

> address@hidden Package Naming
> address@hidden 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
> address@hidden 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 definition.
> +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 packaged

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")

> address@hidden Version Numbers
> address@hidden 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 
> different
> +Scheme variable names. We use the name as defined in @ref {Package Naming}

s/defined in @ref {Package Naming}/previously defined (@pxref{Package Naming})/

> +for the most recent version; previous versions use the same name, suffixed
> +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:
> address@hidden
> +(define-public gtk+
> +  (package
> +   (name "gtk+")
> +   (version "3.9.12")
> +   ...))
> +(define-public gtk+-2
> +  (package
> +   (name "gtk+")
> +   (version "2.24.20")
> +   ...))
> address@hidden example
> +If we also wanted GTK+ 3.8.2, this would be packaged as
> address@hidden
> +(define-public gtk+-3.8
> +  (package
> +   (name "gtk+")
> +   (version "3.8.2")
> +   ...))
> address@hidden example

Add linebreaks around @example, possibly with @noindent before the
lonely lines.

> address@hidden Python Modules
> address@hidden Python Modules
> +
> +We currently package Python 2 and Python 3, under the Scheme variable names
> address@hidden 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 “Some modules”.

Also, please leave two spaces after an end-of-sentence period.

Thanks,
Ludo’.