[pacman-dev] code reuse for PKGBUILD

[Kent Fredric]

On 7 December 2012 07:17, William Giokas <1007380 at 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