Creating -libre packages
This article describes the process of creating -libre packages, that is, how to replace packages from Archlinux that contain non-free code or dependencies.
Contents
1 Prerequisites
- Basic knowledge of how an Arch package is built is needed (PKGBUILDs, makepkg + its flags, etc.). Having practiced with the amazing AUR is a good experience.
- Hang around on #parabola and/or subscribe to packages on our mailing list.
- Follow instructions on our Package maintainer guide
- Update makepkg.conf from makepkg.conf.pacnew if you haven't already.
- Configure ~/.makepkg.conf especially the PACKAGE OUTPUT section, that's near the end of the file.
2 Creating a libre Package
We refer to a libre package as a package that replaces a non-libre package from Arch's official repositories. Sometimes the package doesn't share the same name, like firefox becoming icecat.
A libre package is created in the following cases:
- The package is non-libre but a libre replacement is available.
- The package has some non-libre parts, but is functional without them.
- The package depends on other non-libre packages, but is functional without them.
- The package recommends non-libre software.
3 How to edit the PKGBUILD
3.1 The easy part
To make a libre package the original PKGBUILD needs to be changed.
- A libre package needs to replace the non-libre one, previously this was achieved with
provides=("nonlibrepackage=$pkgver") replaces=('nonlibrepackage') conflicts=('nonlibrepackage')Nowadays .parabola${PARABOLA_RELEASE_COUNT} is appended to pkgrel, for instance:
pkgrel=5becomes
pkgrel=5.parabola1
- Non-libre dependencies must be removed. To identify them, there's a libretools script called pkgbuild-check-nonfree for checking if a PKGBUILD has non-free dependencies. Remove non-free dependencies from
depends=()
- If a patch is needed add it to
sources=()
- If the parts we removed were the only ones which had a custom license, remove "custom" from
license=()
- Add an indication of the change to
pkgdesc='description.'
3.2 The hard part
3.2.1 The mksource and prepare functions
There is not much documentation about how to write mksource() functions, so the best way is to download the abslibre repository and to look for examples in PKGBUILDs that use mksource().
For building packages with mksource(), you can use libremakepkg as usual. However if you use makepkg, you need to have libretools installed, because it requires librefetch to build the PKGBUILD.
For more in depth information:
- The librefetch manual also has some interesting high level information on how mksources() works behind the scenes.
- For even more in depth information, the mksource() article has more details about the mksource design.
3.2.2 The build function
Find if any option on the build function contains the building steps of the software. Make all the modifications needed to build only free sources.
3.2.3 The package function
If the PKGBUILD contains a package function, take the steps needed to avoid installing non-libre stuff. Also make sure the corresponding licenses are correctly installed on /usr/share/licenses/$pkgname if they're not the common licenses.
4 Building
The best way to package is using a clean chroot if you have followed the Package maintainer guide:
# libremakepkg
If everything went OK, test it.
Now, if you're already a Parabola Package Monkey (with a badge and access to the server) you'll have to stage the package and upload it. For signing several packages/sources, you can run gpg-agent, so you'll only have to enter your password once.
$ librestage $repo $ gpg-agent $ librerelease
After the next librerelease runs db-update, so the package(s) will be included in the repo(s) immediately.
db-update
run it will be included in the repository database.
$ makepkg --sourcesend the *.src.tar.gz for revision and expect some applause :-) .
5 Add PKGBUILD to abslibre
Clone the AbsLibre git repo:
* git clone https://git.parabola.nu/abslibre.git
Change to the repo dir
* cd abslibre/$repo
Create dir same as your package name
* mkdir yourpackage
Copy PKGBUILD and build related files (patches) to that dir. Add these copied files to the git
* git add yourpackage/yourfiles
(Make sure that ~/.gitconfig does have 'name' and 'email' fields in it.)
After a succesful build, commit using following command
* git commit -m"Adding yourpackage\n\nSome more information"
Sync the repo
* git push
5.1 Open a Freedom Bug Ticket
All libre replacements on the blacklist should have an associated ticket on the Redmine issue tracker, with "Issue Concern" set to 'Freedom Bug'. This is important for documentation purposes, future reviews, or as the blacklist replacement reference.
Be sure to read the How_to_Blacklist_a_package article, to properly create the blacklist entry.
5.2 Add package details to libre-packages article
After creating the libre-package, please add it to the Libre-packages page on this wiki, with the same terse description/solution as the blacklist file, and linking to the bug report referenced in the blacklist file. Then ensure that the bug report has all of the known details, describing the problem and the solution.
6 Adopting and Maintaining
If you want to maintain a package (please do!) ask another packager for commit permissions.