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