Best practices for packaging older libs (for private use or for the aur)


following up with arch, Manjaro has recently updated sundials to version 7.0.0, that introduces quite a lot of breaking changes wrt version 6.x, so that almost no other thing relying on it seems to have caught up yet (at least under the restricted perspective of the software that I use). Most notably, the Python/SciPy interface to sundials in scikits.odes still needs version 6.

For this reason, I have (re)built a sundials 6.7.0-2 package against my current system using the PKGBUILD file in the arch git repo for the package. So far so good.

However, using this may become problematic in the future. So I was wondering about making a sundials6-compat package for my own usage (or to be placed in the aur), capable of coexisting with the official sundials package. My questions is whether there are best practices this kind of thing or examples to rely upon, particularly because I need not just the libs, but the headers too (otherwise scikits.odes cannot be installed). Is using /usr/include/sundials6/... as a prefix OK, or is using the opt hierarchy considered a better option?


This should cover best practise Arch package guidelines - ArchWiki

1 Like