[Dev] [RFC] Package naming for packages modified from Arch

Luke Shumaker lukeshu at sbcglobal.net
Wed Jul 30 04:36:50 GMT 2014

At Emulatorman's suggestion, I am taking this discussion from the IRC
channel to the mailing list.

The topic is basically "when should we add '-libre' to a package name?"

We may also end up discussing the CONFIG_LOCALVERSION for kernels.


The following 4 suggestions have been offered: (as I understand them;
with some commentary added)

 1) Add the -libre suffix to all packages that are modified from Arch
    for freedom reasons (so not for rebranding reasons). (fauno)

    lukeshu: Why "except for rebranding"?

 2) Add the -libre suffix on packages for patched-source software.

    lukeshu: Because the name "${pkgbase}-libre" denotes that it is a
    fork of "${pkgbase}" that is maintained by the Parabola project,
    similar to Iceweasel being maintained by Debian, or Linux-libre by
    GNU/the FSFLA.

 3) Don't ever use the -libre suffix (mtjm)

    Because all packages on [libre] have implicitly been modified for

 4) Use -libre for patched-source software, and -prbl/-para (or similar)
    for packaging or configuration chages. (coadde)

    The "-libre" policy from #2, plus using another suffix to
    differentiate between Arch's version and Parabola's version to
    avoid confusion when migrating.

    Basstard`: prbl is not far from prblm.


This was previously briefly discussed on-list in January 2013:
 - https://lists.parabolagnulinux.org/pipermail/dev/2013-January/001054.html
 - https://lists.parabolagnulinux.org/pipermail/dev/2013-January/001056.html

I'm sure it has been discussed in much more detail on IRC; but I do
not have IRC logs.

Other relevent resources:
 - https://wiki.parabolagnulinux.org/Nomenclature
 - Arch's documented naming policies:
   - https://wiki.archlinux.org/index.php/Arch_packaging_standards#Package_naming
   - https://wiki.archlinux.org/index.php/Cross_Compiling_Tools_Package_Guidelines#Package_naming
   - https://wiki.archlinux.org/index.php/Eclipse_Plugin_Package_Guidelines#Package_naming
   - https://wiki.archlinux.org/index.php/Free_Pascal_PKGBUILD_Guidelines#Package_naming
   - https://wiki.archlinux.org/index.php/Go_Package_Guidelines#Naming
   - https://wiki.archlinux.org/index.php/Java_Package_Guidelines#Java_packaging_on_Arch_Linux
   - https://wiki.archlinux.org/index.php/KDE_Package_Guidelines#Package_naming
   - https://wiki.archlinux.org/index.php/MinGW_PKGBUILD_Guidelines#Package_naming
   - https://wiki.archlinux.org/index.php/OCaml_Package_Guidelines#Package_naming
   - https://wiki.archlinux.org/index.php/Perl_Package_Guidelines#Package_names
   - https://wiki.archlinux.org/index.php/Python_Package_Guidelines#Package_naming
   - https://wiki.archlinux.org/index.php/Ruby_Gem_Package_Guidelines#Package_naming
   - https://wiki.archlinux.org/index.php/VCS_PKGBUILD_Guidelines#Guidelines
 - I can't seem to find the AUR rules right now.


A look at Arch's policy:

The only documented use of pkgname suffixes in Arch's policies is: 
 - for VCS packages, which allow "`-cvs`, `-svn`, `-hg`, `-darcs`,
   `-bzr`, `-git`, etc."
 - The major version is used in the case of multiple supported release
   branches.  Examples:
   - `gtk2`/`gtk3`
   - `qt4`/`qt5`

However, from knowledge of Arch, they also use suffixes for:
 - A significant alternate configuration.  Examples:
   - `emacs` -> `emacs-nox` (extra->community) (sort-of conflicts with
     using `emacs-$modename` for Emacs modes)
   - `linux` -> `linux-pae` (AUR)
 - A nonstandard release branch is used.  Examples:
   - `linux` -> `linux-lts` (core)
 - A patchseries has been applied.  Examples:
   - `linux` -> `linux-grsec` (core->community)

(I'm almost certain non-"linux" examples could be found for each, I'm
just lazy/tired).


A look at existing practice in Parabola:

 - abiword -> abiword-libre: Has been patched to alter defaults
   referencing non-free files.  This is a "configuration" change, but
   hardcoded configuration.  This patch is maintained by Parabola.

 - abs -> abs: The same software as in Arch, but with a different
   configuration file in /etc.  This was named 'abs-libre' until I
   renamed it to 'abs' in June 2013.

 - acpi_call -> acpi_call-libre; acpi_call-lts -> acpi_call-libre-lts: Must be compiled
   per-kernel.  The suffix is based on the kernel name.  In the
   morning when I'm less tired, I will update on details about kernel
   naming policies in Arch vs. Parabola.

 - antlr2 -> antlr2: The same software, packaged/built differently
   because of differing policies on Java packages.

 - apache-ant -> apache-ant: The same software, but the Parabola
   package is built from source, where the Arch PKGBUILD fetches a
   precompiled binary.

 - filesystem -> filesystem: No software at all.  Contains branding

 - linux -> linux-libre: The Arch software has been replaced by
   software from a different upstream.  In the morning when I'm less
   tired, I will update on details about kernel naming policies in
   Arch vs. Parabola.

 - firefox -> icecat: The Arch software has been replaced by software
   from a different upstream.

 - firefox -> iceweasel-libre: The Arch software has been replaced by
   software from a different upstream, AND that software has then been
   patched for freedom-related reasons.  The patch is maintained by

 - cups-filters -> cups-filters-libre: Exactly the same package,
   except that an entry has been removed from the `optdepends` array.

 - mplayer -> mplayer-libre: Identical, except that mplayer-libre
   lacks 'faac' as a dependency (the presence/absense of faac is
   detected by ./configure).

I *think* that covers every distinct way a package is changed--though
I do not believe renaming is performed consistently enough for
policies to be created from this set.

When the package being renamed is a split package, I believe the
policy is universally:


    if [[ "${arch_pkgname#"$arch_pkgbase"}" == "${arch_pkgname}" ]]; then
        # the pkgname is NOT based on the pkgbase
        # the pkgname IS based on pkgbase

Happy hacking,
~ Luke Shumaker

More information about the Dev mailing list