[pacman-dev] code reuse for PKGBUILD

[Jason St. John]

On Thu, Dec 6, 2012 at 1:17 PM, William Giokas <1007380 at gmail.com> wrote:
> 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
>
>
>

I think Kent's suggestions would be better targeted at
PKGBUILD-perl.proto, which is a part of abs[1] instead of the primary
PKGBUILD.proto which is shipped with pacman.

[1] https://projects.archlinux.org/abs.git/tree/prototypes/PKGBUILD-perl.proto

Jason