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