[pacman-dev] code reuse for PKGBUILD

Thu Dec 6 13:17:01 EST 2012

On Fri, Dec 07, 2012 at 06:38:52AM +1300, Kent Fredric wrote:
> 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.
First off, welcome, and I hope I can help answer some questions for you.
I've never packages a perl module, but I'll answer what I can.
> 
> *~~~ 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
It is the job of the community to keep AUR PKGBUILDs up to date. It's
called the Arch *User* Repository for a reason. 

> 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.
> 
About the .packlist files, open up /etc/makepkg.conf and checkout
PURGE_TARGETS. You'll notice that haveing the option "purge" in the
options array will remove the files listed in PURGE_TARGETS. .packlist
is in there. To stop this, add `options=('!purge')` to a pkgbuild,
overriding the user settings. 

> 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.
The package and check functions are fairly new, but I do know that in
the development version of pacman it warns about not having a build()
function.

> 
> 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
> 
I'm no expert on perl, but in the next release of pacman, there is the
option to include a pkgver() function that is run after the sources are
acquired. While I see this being very useful in vcs packages, it could
also be used to normalize perl version numbers.
> 
> 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.
> 
PKGBUILDs are not just for perl packages, and this is required for all
PKGBUILDs. I'd say this is not going to change.
> 
> 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
I think it would be easiest to have the submitter input the url so that
the AUR doesn't have to parse anything, otherwise people would most
likely find a way to have _perl_distname become malicious. 
> 
> source=() is also omitted, as the primary src URI can also be divined from
> combining _perl_distname  , _perl_author and _perl_ver
source is one of those required things if you're going to do checksums.
I don't see how adding 3 variables that are perl-specific is better than
taking away 3 variables that are language agnostic. 
> 
> 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.
If this were true, then things would be oh so much easier. As it is, not
everything builds with a simple set of build() → check() → package()
instructions, and customizing these is one of the important things in a
PKGBUILD.
> 
> 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
> 
While I do agree that some improvements could be made, perl modules are
a tiny subset of what PKGBUILDs are written for. VCS support was added
because many AUR packages are -git, -hg, etc. Should we do the same for
Python packages, for Haskell packages?
> 
> 
> In advance, thanks for your consideration =).

Also, while not every AUR perl packager reads it, you could really help
by contributing to the Perl Packaging Guidelines on the wiki [1].

[1] https://wiki.archlinux.org/index.php/Perl_Package_Guidelines#Module

-- 
William Giokas | KaiSforza
GnuPG Key: 0xE99A7F0F
Fingerprint: F078 CFF2 45E8 1E72 6D5A  8653 CDF5 E7A5 E99A 7F0F
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/pacman-dev/attachments/20121206/fc2d9e10/attachment-0001.asc>