On 7 December 2012 07:17, William Giokas <1007380@gmail.com> wrote:
It is the job of the community to keep AUR PKGBUILDs up to date. It's called the Arch *User* Repository for a reason.
Yes, but making it easier to have them stay "up to date", and having "good behaviours" updated independent of the individual PKGBUILD files would mostly be a good thing.
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.
Ah!, all these 'find/delete' stanzas are just more silly cargo-culting that could be removed. In essence, you've got a feature in makepkg to eliminate these files, and dozens of Perl PKGBUILD file .... manually re-implement this function in ways that veto user choice :(
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.
The important point to understand in my proposal is the "extensions=('perl-module')" would dynamically inject the build() stub to a "good default" provided by the perl-module extension.
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')
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.
This shall hopefully prove quite useful =)
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.
The point is really, I'm not suggesting "Change all of PKGBuild in this way", I'm more suggesting the "extension" stanza, which changes behaviour within the context of that one PKGBUILD. So it wouldn't change for *all* PKGBUILD, only PKGBUILD that have `extensions=('perl-module')` , ie: perl-module provides a default license.
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.
There's not many, if any ways to make it malicious, its basically : url="http://search.cpan.org/dist/${_perl_distname}/" or url="http://metacpan.org/release/${_perl_distname}/" If there's a way to be malicious there, well, I might have missed something serious in how HTTP works =)
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.
Note of course, converting these variables to a source() value would be a task of the extension loaded earlier, not simply having global magic code that works in the presence of these variables.
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.
Of course as I stated earlier, there would be "Sane defaults" provided by loading the "perl-module" extension, and you *can* have sane defaults for 99% of Perl Modules on CPAN, and for cases where you needed to override these defaults, simply declaring build() explicitly would override the default behaviour.
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?
Sure, but these are feature sets that are best handled modularly, with per PKGBUILD opt-in behaviour, and there could easily be modules for git/hg/svn to streamline PKGBUILD authoring , and, if designed right, you could even use a combination of these modules in the same file, ie: `extensions=('perl-module' 'git')` Essentially, every time you'd have some sort of "model" example of a Git or Perl module PKGBUILD, instead of hand copying code each and every time, the code copying would be something handled at makepkg level, and happen each and every time you ran makepkg. And this is more or less how Gentoo works. For instance, with Git, you "inherit git" , and then specify a few variables specific to the git extension, and the git extension adds the right code required to clone and check out the repo / branch / commit and get you a working source tree transparently. And if we wanted to add support for a new SCM , we could do so without having to touch the core build toolkit, all that would be required is a new extension for that SCM. -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz