On Thu, Dec 6, 2012 at 1:17 PM, William Giokas <[email protected]> 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
