[pacman-dev] code reuse for PKGBUILD

[Kent Fredric]

So, I'm sort of new to Arch, but I've already found some things in how a
few things work I have rather sizable miss-givings about, and see room for
improvement.

*~~~ BEGIN CONFUSING RANT HERE ~~~*
*( or skip past it to the TL;DR )*

The primary one at present is "No code re-use in PKGBUILD. Period"

And this strikes me as a bad idea.

I understand that having a PKGBUILD become not fully independent might be
undesirable to some, but I'm hoping there is a pivotal middle-ground that
can be useful.

1. Many PKGBUILD files are seriously outdated
2. Each and every Perl Module PKGBUILD requires the author to know
*everything* about packaging Perl modules, and this is a somewhat hard
thing to know:

   -  version normalisation  # I haven't seen anyone do it yet, and its the
only sure-fire mechanism to get versions to play nicely together.
   -  lots of boilerplate , cargo-cult copypasted around, see :
https://aur.archlinux.org/packages/pe/perl-json-any/PKGBUILD

Consider this for a moment: Gentoo, like Arch have been nuking '.packlist'
files for some time, until recently it became apparent that some programs
actually need those files to do their job.

https://bugs.gentoo.org/show_bug.cgi?id=438660

This is "bad practice", and because the behaviour is not codified in some
shared library that all perl module packages use, in order to "Fix" this
problem on arch, it requires a considerable number of person-hours to vet
the hundreds of perl PKGBUILDS to eliminate this behaviour.

https://aur.archlinux.org/packages/pe/perl-devel-nytprof/PKGBUILD

Another bad example of people reinventing all their own wheels, and doing
all make/make test/make install during build. This behaviour should really
be codified in a shared module.

That way, when people realise the way the shared module has been doing
things is for whatever reason, wrong, its simply a matter of fixing that,
and every build past and present benefits from the change, with no
additional effort on the PKGBUILD maintainers.

What I hope to do is find some sort of consensus on how it would be best to
add a little bit of code-reuse to pkgbuild, as this will, I feel, greatly
improve maintenance of these files.

Because *both* of those 2 PKGBUILD files I posted could have been easily
refactored, and had *100%* of their independent code eliminated in favour
of shared behaviour.


extensions=('perl-module')
_perl_distname=json-any
_perl_ver='1.29'
_perl_author=PERIGRIN
pkgver='1.290.0'
pkgrel='1'

pkgdesc="Wrapper Class for the various JSON classes."
arch=('any')

options=('!emptydirs')
depends=('perl-json>=2.02' 'perl-json-xs>=2.3' 'perl-yaml-syck')
makedepends=()
md5sums=('f7eea523d532668555456e4153334342')



Notes:

_perl_ver and pkgver are different due to my recommendation that upstream
versions undergo a normalisation process prior to being used for arch
versions.

This is important, as perl versioning semantics are wildly different from
the rest of the worlds. The average packager will not even realise how big
a deal this is, but simple to say, perl versions are a nightmare:
http://www.dagolden.com/index.php/369/version-numbers-should-be-boring/

On Gentoo, we've developed a tool to make it easier to convert perl
versions to versions we can use in packages, and it basically "Just works".
https://metacpan.org/module/Gentoo::PerlMod::Version


license= is omitted, as  this way, it can default to the most common
license on CPAN, "The Perl5 License" ->   license=('PerlArtistic' 'GPL') and
can be overridden as needed.


url= is omitted, as this can easily be generated from the _perl_distname
value, and overridden only when necessary.  This means you can either have
the underlying module refer to pages on search.cpan.org, or metacpan.org

source=() is also omitted, as the primary src URI can also be divined from
combining _perl_distname  , _perl_author and _perl_ver

and you can usually leave out build(), check() and package(), as these
phases are all very well known and have to meet a standard behaviour to
operate with 'cpan' clients, so its quite straightforward to have a set of
default behaviours.

Implementation wise, my biggest question is "Where is 'perl-module'
stored".

The simplest option is a pacman distribution, such as 'pacman-extensions',
that installs files in /usr/lib/pacman/extension/  , and makepkg/pacman can
be made aware of this feature and load the modules on demand.

For those who don't like the inherent issue where "PKGBUILD depends on code
outside tar.gz", it could be engineered so that `makepkg -S` copies files
from /usr/lib/pacman/extension/ into the built tree at  /extensions/ , and
then have some sort of mechanic that chooses between using the "system"
version of the extension or the "bundled" version of the extension.

With built packages, the behaviours from the extension would probably have
to be cooked in to the dist ( somehow ), but thats an accepted caveat of
how binary distribution usually works.



*========= TL;DR TL;DR TL;DR TL;DR TL;DR =========*

1. I'm a noob to Arch
2. ... But I have substantial experience packaging perl modules for gentoo
 ( https://github.com/gentoo-perl/perl-experimental/graphs/contributors ,
https://www.ohloh.net/p/gentoo-perl- overlay/contributors/summary  )
3. And I strongly feel that in regard to packaging things, the PKGBUILD
spec at present seems a little immature
4. And I strongly feel, that PKGBUILD could gain a great deal of
improvement utility by having /some/ shared code mechanism
5. ... But I'm not quite sure what the best way to do this is
6. And I'm strongly against any ideas that involve developing a *Second*
platform that simply emits files in the PKGBUILD format, or implementing
competing products to `makepkg`
7. And I'd rather *not* have hard-inlining behaviour , I'm fine with the
external behaviour being shipped independently, but if thats not universal,
then I'd like to find a middleground



In advance, thanks for your consideration =).



-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 )
for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz