[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)
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
freedom.
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
changes.
- 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
Parabola.
- 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:
para_pkgbase=${arch_pkgbase}-libre
if [[ "${arch_pkgname#"$arch_pkgbase"}" == "${arch_pkgname}" ]]; then
# the pkgname is NOT based on the pkgbase
para_pkgname="${arch_pkgname}-libre"
else
# the pkgname IS based on pkgbase
para_pkgname="${para_pkgbase}${arch_pkgname#"${arch_pkgbase}"}"
fi
--
Happy hacking,
~ Luke Shumaker
More information about the Dev
mailing list