[pacman-dev] code reuse for PKGBUILD
1007380 at gmail.com
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
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 :
> 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.
> 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.
> 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()
> 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.
> pkgdesc="Wrapper Class for the various JSON classes."
> depends=('perl-json>=2.02' 'perl-json-xs>=2.3' 'perl-yaml-syck')
> _perl_ver and pkgver are different due to my recommendation that upstream
> versions undergo a normalisation process prior to being used for arch
> 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:
> 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".
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
> Implementation wise, my biggest question is "Where is 'perl-module'
> 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 .
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
Size: 490 bytes
Desc: not available
More information about the pacman-dev