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

Luke Shumaker lukeshu at sbcglobal.net
Tue Aug 19 02:06:28 GMT 2014


I did my research on kernel naming policies!

At Wed, 30 Jul 2014 00:36:50 -0400,
Luke Shumaker wrote:
...
> We may also end up discussing the CONFIG_LOCALVERSION for kernels.
...
> 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:
...
>  - 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.
...
>  - 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.

(This summary of policies ignores beta/development builds)

----

Linux kernel versions are in the format:

    $(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)$(LOCALVERSION)

Everyone mostly agrees on how to set VERSION/PATCHLEVEL/SUBLEVEL
(though not always what to call the variables in build scripts :P),
but EXTRAVERSION and LOCALVERSION vary a bit:

    +------------------------------+--------------+--------------+
    |                              | EXTRAVERSION | LOCALVERSION |
    +------------------------------+--------------+--------------+
    | Linux (stable)               | ''           | ''           |
    | Linux-libre                  | '-gnu${rel}' | ''           |
    | Arch Linux's 'linux'         | '-${pkgrel}' | '-ARCH'      |
    | Arch Linux's 'linux-lts'     | '-${pkgrel}' | '-lts'       |
    | Parabola's 'linux-libre'     | '-${pkgrel}' | '-libre'     |
    | Parabola's 'linux-libre-lts' | '-${pkgrel}' | '-libre-lts' |
    +------------------------------+--------------+--------------+

----

I mentioned we sometimes disagree on variable names:

  Arch Linux:

    _kernelname=...
    pkgbase=linux${_kernelname}

    _basekernel=${VERSION}.${PATCHLEVEL}
    _srcname=linux-${VERSION}.${PATCHLEVEL}
    pkgver=${VERSION}.${PATCHLEVEL}.${SUBLEVEL}
    EXTRAVERSION=-${pkgrel}
    LOCALVERSION=${_kernelname:--ARCH}

  Parabola:

    _kernelname=...
    _localversionname=-libre-${_kernelname}
    pkgbase=linux${_localversionname}

    _basekernel=${VERSION}.${PATCHLEVEL}
    _sublevel=${SUBLEVEL}
    EXTRAVERSION=-${pkgrel}
    LOCALVERSION=${_localversionname}

That is, Parabola's _localversionname takes the place of Arch's
_kernelname, and Parabola's _kernelname is roughly "what would
_kernelname be in Arch?".

----

Now, names of non-kernel packages that must match the kernel.

In Arch, packages that must be compiled per-kernel get the pkgname
suffix "$_kernelname".  In Parabola, it is the same thing (but
$_localversioname, since we changed the meaning of $_kernelname).

-- 
Happy hacking,
~ Luke Shumaker



More information about the Dev mailing list