Ports packaging guidelines
The aim of this page is to list some ways to make packaging for non-Arch architectures easier, keep ports-specific differences small and avoid some problems when building, updating or using packages.
Contents
- 1 Don't do other changes to arch= arrrays than adding your architecture name
- 2 Don't enable additional gcc warnings
- 3 Sometimes missing dependencies are caused by cleansystem being updated
- 4 Don't change epoch
- 5 Don't change pkgver unless to newer version fixing a problem
- 6 Don't change pkgrel main number
- 7 Don't do multiple uploads of the same pkgrel
- 8 Don't change pkgrel when just fixing a build error
- 9 Don't do unneeded changes
- 10 Don't update config.guess or config.sub
- 11 Don't special-case adding -fPIC for mips64el
- 12 Don't duplicate dependency arrays
- 13 Don't rename packages
- 14 Make changes to packages from repos included in abslibre directly there
- 15 Don't do any changes for FSDG-compatibility
- 16 Always use fullpkg or treepkg for building a package with its dependencies
1 Don't do other changes to arch= arrrays than adding your architecture name
It's useful to build the package on e.g. x86_64, since some bugs can be reproduced there and fixed on faster machines.
2 Don't enable additional gcc warnings
There is no need for them. Fixing them should be done upstream.
3 Sometimes missing dependencies are caused by cleansystem being updated
Update it and install missing packages in the chroot instead of adding e.g. pkg-config to makedepends.
4 Don't change epoch
No architecture-specific change requires redoing package versioning scheme while this is the only use of epoch.
5 Don't change pkgver unless to newer version fixing a problem
Reset pkgrel=1 in that case.
6 Don't change pkgrel main number
This is needed to know if rebuilds due to Arch changes are needed; increase the second number.
7 Don't do multiple uploads of the same pkgrel
Add .1 to it (e.g. 3 -> 3.1, 3.1 -> 3.2).
8 Don't change pkgrel when just fixing a build error
There are other reasons to change it if e.g. a rebuild is needed to use different libraries. If the change doesn't affect user systems and only one package of specific pkgrel is uploaded, there is no need to change it.
Examples: first successful build of a package for a new architecture, unimportant optimizations or test fixes that can wait for the next pkgrel.
9 Don't do unneeded changes
It's ok to make a package build or work faster on mips64el, or to use user-specified CFLAGS, it's not to change whitespace or commas in package description, unless having other reasons to change that line.
10 Don't update config.guess or config.sub
Add these arguments to configure:
--build=$CHOST --host=$CHOST
(--target=$CHOST is also needed in case of compilers, usually it being used is a bug). Ask upstream to update config.guess and config.sub for next release and blame KISS for PKGBUILDs not using a configure wrapper adding these and other generally useful options.
11 Don't special-case adding -fPIC for mips64el
Do this instead:
- [ "$CARCH" = "x86_64" ] && CFLAGS+=" -fPIC" + [ "$CARCH" != "i686" ] && CFLAGS+=" -fPIC"
or, preferrably, make upstream and Arch packages build with shared libraries.
12 Don't duplicate dependency arrays
It makes merging Arch changes difficult, instead remove the arch-specific ones and append them in a conditional.
13 Don't rename packages
There is no reason for this to be needed just for one arch; non FSDG-compatible names should be fixed in abslibre.
14 Make changes to packages from repos included in abslibre directly there
This avoids having to fix build problems twice or to merge arch-specific changes (and the confusion of having two different PKGBUILDs possibly used to build a specific package).
15 Don't do any changes for FSDG-compatibility
They are always needed on all arches, abslibre is a better place for them (and makes the change more visible for other distros).
16 Always use fullpkg or treepkg for building a package with its dependencies
Otherwise packages will fail, build broken or break after updating the dependencies later without a clear indication that they need rebuilding. Toolchain updates are an exception, they need special ordering and are more difficult in some cases.