[pacman-dev] code reuse for PKGBUILD

[Kent Fredric]

If you want to see something

A. Scary
B. Along the lines of what I'm asking
C. To see how most of this is pretty easy to implement with just plain old
bash

https://gist.github.com/4227633#file_pkgbuild

^

Works.
- makepkg -S  # works as expected
- makepkg      # works as expected

All I'm basically asking for is "hey, maybe that perlmod.sh file should be
shared, and put in a place where only people we trust are editing it"

After all, that would *increase* security, and decrease the need for every
PKGBUILD to be so heavily reviewed for exploits.


On 7 December 2012 06:38, Kent Fredric <kentfredric at gmail.com> 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.
>
> *~~~ 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
> 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.
>
> 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.
>
> 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
>
>
> 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.
>
>
> 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
>
> source=() is also omitted, as the primary src URI can also be divined from
> combining _perl_distname  , _perl_author and _perl_ver
>
> 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.
>
> 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
>
>
>
> In advance, thanks for your consideration =).
>
>
>
> --
> 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
>



-- 
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