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
pgp8kBSjG8YJG.pgp
Description: PGP signature
