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 =).
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.
- 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.
- 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 =========*
- I'm a noob to Arch
- ... 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
On Thu, Dec 6, 2012 at 1:17 PM, William Giokas 1007380@gmail.com 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.
- 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.
- 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 =========*
- I'm a noob to Arch
- ... 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
On 7 December 2012 07:43, Jason St. John jstjohn@purdue.edu wrote:
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
I am aware of this file somewhat, its just the standard usecase is "See the file, copy its guts, dont understand what they do, suffer the fact the code you copied will get old and wont be updated when the perl.proto is"
The idea is basically, "get the behaviour ascribed in PKGBUILD-perl.proto, except, without needing to manually review that file, and have most the legwork done by a little bit of syntax that loads that behaviour"
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/$%7B_perl_distname%7D/"
or
url="http://metacpan.org/release/$%7B_perl_distname%7D/"
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.
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@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.
- Many PKGBUILD files are seriously outdated
- 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 =========*
- I'm a noob to Arch
- ... 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 );"
Bah, the only thing stopping that working, is AUR needs static fields without variable interpolation :(
Lame.
Kent,
I'm a new Arch-user having interest eventually to contribute if I can, so please take with a grain of salt my opinion. I do not know enough the pacman-dev community to predict how your suggestions will be perceived. I see some merits in them but here are important benefits of the "no code reuse" policy.
1. Avoiding dependency issues in a system that manage dependencies is a good thing. With your suggestion, you would eventually end up with PKGBUILD not immediately usable because you need to update your reusable perl module
2. "no code reuse" also implicitly enforce KISS
While I love Perl for some tasks such as processing nm output to create automatically bps in gdb, I feel that some languages weren't meant for reusability, with all respect for Perl, I believe that it is one them.
My past experience for having work a year in a Perl shop is that, give just a couple of months to a reusable Perl module and it will at some point use OO Perl with Moose that needs a special module to highjack the import statement so that lookups in a serie of yaml files are performed to build dynamically the module search path env for the hundreds of required Perl module and the beast will grow to several hundred of MBs during runtime and will become slow like a camel with a moose head. It will become so complex that no mere mortals will understand what is going on, when the thing breaks.
I started to play with PKGBUILD files and I just like them as they are.
That is just my opinion.
Greetings, Olivier
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.
________________________________ CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.
On 7 December 2012 09:30, LANGLOIS Olivier PIS -EXT < olivier.pis.langlois@transport.alstom.com> wrote:
Kent,
- Avoiding dependency issues in a system that manage dependencies is a
good thing. With your suggestion, you would eventually end up with PKGBUILD not immediately usable because you need to update your reusable perl module
Indeed, but this is why its best to have this reusable "module" ( not a perl module, just bash really ) distributed via some more authoritative measure, so that although it will update periodically, people who write code to use these 'modules' can rely on them existing.
On gentoo, this guarantee is given by the fact that these modules reside in the main repository tree, so for official packages, all thats required is to make sure the requisite "modules" ( we call them 'eclasses' but they're basically just specialised bash scripts ) are committed to tree .
This way, although there is a degree of dependency, its about as moot a point as PKGBUILDS having patches ship with them which are also "Dependencies".
- "no code reuse" also implicitly enforce KISS
I've seen anything but KISS in the PKGBUILDS I'm seeing. Many of them have cargoculting all over them.
And there is also the concept that complexity is immutable, you can only manage it by moving it around, you cant eliminate it entirely.
And with perl modules in particular, packaging them has many forms of unavoidable complexities .
The fact upstream depend on *modules* , not packages, and packages have multiple modules, creates an entire host of problems. ( And this is especially bad when you compound that with packages depending on a specific version of a module, and the package that module of that version being shipped in not being correlated in any way to the package version itself )
And then you have package splits/merges where the package a module is shipped in is vulnerable to change over time.
These 2 problems are at present somewhat unsolveable in realsitic ways.
There are however a few cases of things we can easily solve, and many of the boiler plate code copied into each and every PKGBUILD does just this.
ie: Upstream sometimes opt to change their distribution toolkit, and might change from EUMM to MB without any obvious other changes. Its quite easy to codify behaviour to handle this case, so you don't have to worry about this.
But this is starting to get distracted.
The benefits from this are that:
1. Maintaining a module often requires you to change many fields 2. The more fields you have to change, the more likely you'll make a mistake and something will go wrong. 3. Even the recommended behaviours in the Perl Guide for Arch are pretty arbitrary and confusing , and require that every maintainer of every perl module pay very close attention to the guide to keep their installation to "best practices", ie: - having to make sure they install to vendor - having to make sure they set the right ENV values so that EUMM won't explode if test-deps aren't satisified during build - knowing what toolkit they're using and what the right invocations are for that toolkit
And some of these are "Policy based", ie: what happens if 6 months from now, whoever is head of Arch perl stuff decides their "install to vendor" behaviour is wrong, instead of just changing the install mechanic for *all* perl module installations and being done with it, they have to a. Document the change b. Inform developers of the change c. Wait 12 - 36 months for the changes to propagate ...
In essence, the benefits from having a reusable shareable blob of managed code are real, for exactly the same reason that "using a library" is a superior choice to "blindly copy paste the code" in *every programming language I know of* .
While the negatives of this are hard to quantify, and are possibly only * perceived* negatives, not *actual* negatives.
ie: We do exactly this in Gentoo, we do it all the time, we leverage it extensively. All the paranoid rationale for why it is bad : Never happens.
While I love Perl for some tasks such as processing nm output to create automatically bps in gdb, I feel that some languages weren't meant for reusability, with all respect for Perl, I believe that it is one them.
My past experience for having work a year in a Perl shop is that, give just a couple of months to a reusable Perl module and it will at some point use OO Perl with Moose that needs a special module to highjack the import statement so that lookups in a serie of yaml files are performed to build dynamically the module search path env for the hundreds of required Perl module and the beast will grow to several hundred of MBs during runtime and will become slow like a camel with a moose head. It will become so complex that no mere mortals will understand what is going on, when the thing breaks.
I'm not sure what you're trying to say here, if you're saying "In perl, you shouldn't use modules, you should just inline all the code", then I'll have to politely disagree.
If you inline the code, then *you* have to maintain all the bugs in that code, and *all code has bugs hiding in it*. All you achieve by inlining it, is that when upstream discover the bugs, and fix them, your code will still be vulnerable!
And this is basically the foundation of this suggestion, provide a way to optimise the usecases for various classes of problems, to streamline development, so that the time for maintaining a package is substantially reduced.
And consider, from a security perspective, which is safter:
1. Having dozens of PKGBUILDS contributed by users, each with *many* *many* lines of arbitrary executable code that end users will have neither time, knowledge, or patience to manually vet
or
2. Equally many PKGBUILDS contributed by many users, but most of them have little to no exectuble code to review, because it simply uses default behaviours borrowed from libraries published by a well trusted authority, and these libraries have each been reviewed thousands of times by people who know what they're doing.
Or, to put simply, which is easier to review for security risks?
https://gist.github.com/4229354 # where "/usr/lib/pacman/extensions/perl-module.shlib" is produced by a trusted authority ... or
https://gist.github.com/4229359 # this big mess of code which could easily hide any number of security flaws.
As it is , a large amount of people just upload stuff made by generation tools, but it would be so easy to put in bad code hiding amongst that , exploiting peoples sense of security in the assumption that the generated code was safe, but hiding a nasty 'sudo rm -rf /' in one of the phases.
By using the library, and removing the need for these blocks of code, you reduce the number of places bad code can lurk.
And somebody reviewing the first of those 2 github links can *quickly* divine the lack of any nefarious code.
So... here is my "official" opinion on this.
1) Would I support adding this to makepkg/pacman? Yes. 2) Would I support Arch Linux using it in any way? No...
But, I could be overridden on the second point if many Arch developers wanted to use it.
I have two issues with this:
Firstly, adding a build module will result in a level of expertise needed to understand what a PKGBUILD will do. At the moment, you can look at a PKGBUILD and see exactly what will be run to build that package. When I look at an ebuild, I can have a good guess at what is done, but given I have never used that system I am not always sure...
Secondly, the advantage that you only need to update the extension file to update many packages is also its disadvantage. Which packages were built with the old prototype? I can now build from a PKGBUILD and get a different result to what I obtained when I first used it.
Allan
On 7 December 2012 15:32, Allan McRae allan@archlinux.org wrote
Secondly, the advantage that you only need to update the extension file to update many packages is also its disadvantage. Which packages were built with the old prototype? I can now build from a PKGBUILD and get a different result to what I obtained when I first used it.
Indeed, its a bit different on Gentoo as the distribution paradigm is quite different.
Repos exist, repos have ebuilds, and repos have ebuilds, and eclasses used by ebuilds are often ( but not always ) found within the same repository.
With AUR, every package is sort of like its own repository in a way, so the gap between the library and the package itself is a bit larger.
The most obvious way around this is probably not a good one either: Having the prototypes embedded in src tgzs during 'makepkg -S' .
This basically puts us back at square one, except now you've got a possibly much larger blob of code floating around that could be hiding secrets. ( ie: somebody could make a mock copy of a trusted prototype that does evil things and people might overlook it, but then again, you can actually do that *now* ).
The only real saving graces there are: 1. you could plausibly have a mechanism that uses the "system" copy of a prototype, not the shipped one. 2. it would actually improve maintenance imo, albeit slight, as maintainers of packages could mentally blackbox those externalities but just keep letting makepkg update them.
Maybe the "Arch" way would be more template based, and maybe it could have a sort of "guard region comment" combined with some automatic content regeneration, ie: https://gist.github.com/4230499
And the stanza "#<<NAMEHERE>>" could serve as a sort of inline template marker, which would automatically get expanded at some stage,
1. NAMEHERE module is loaded 2. NAMEHERE generates content to inline 3. #<<NAMEHERE>> is replaced with #<NAMEHERE:sha=$sha1:v=$version> ( where $sha1 is the sha1 of the content that was inlined, and $version is the version of the module that was used to generate the body. 4. generated content is injected after modified #<<NAMEHERE>> 5. closing #<<-NAMEHERE>> comment is added.
And the result is : https://gist.github.com/4230520
And when a maintainer wants to update the templated data, can just do 'makepkg --maintainer'.
Users who are paranoid could then add an option in makepkg.conf to /always/ regenerate these sections from their local copies, or maybe only regenerate using the same version of that module.
The important part about this way of doing things, is from an end users perspective, its identical, except for the additional strange guard-comments.
The only really big downside I see to the approach is the commenting stuff is a little bit magical.
Allan
On 7 December 2012 16:46, Kent Fredric kentfredric@gmail.com wrote:
On 7 December 2012 15:32, Allan McRae allan@archlinux.org wrote
Secondly, the advantage that you only need to update the extension file to update many packages is also its disadvantage. Which packages were built with the old prototype? I can now build from a PKGBUILD and get a different result to what I obtained when I first used it.
Indeed, its a bit different on Gentoo as the distribution paradigm is quite different.
Repos exist, repos have ebuilds, and repos have ebuilds, and eclasses used by ebuilds are often ( but not always ) found within the same repository.
With AUR, every package is sort of like its own repository in a way, so the gap between the library and the package itself is a bit larger.
The most obvious way around this is probably not a good one either: Having the prototypes embedded in src tgzs during 'makepkg -S' .
This basically puts us back at square one, except now you've got a possibly much larger blob of code floating around that could be hiding secrets. ( ie: somebody could make a mock copy of a trusted prototype that does evil things and people might overlook it, but then again, you can actually do that *now* ).
The only real saving graces there are:
- you could plausibly have a mechanism that uses the "system" copy of
a prototype, not the shipped one. 2. it would actually improve maintenance imo, albeit slight, as maintainers of packages could mentally blackbox those externalities but just keep letting makepkg update them.
Maybe the "Arch" way would be more template based, and maybe it could have a sort of "guard region comment" combined with some automatic content regeneration, ie: https://gist.github.com/4230499
And the stanza "#<<NAMEHERE>>" could serve as a sort of inline template marker, which would automatically get expanded at some stage,
- NAMEHERE module is loaded
- NAMEHERE generates content to inline
- #<<NAMEHERE>> is replaced with #<NAMEHERE:sha=$sha1:v=$version> (
where $sha1 is the sha1 of the content that was inlined, and $version is the version of the module that was used to generate the body. 4. generated content is injected after modified #<<NAMEHERE>> 5. closing #<<-NAMEHERE>> comment is added.
And the result is : https://gist.github.com/4230520
And when a maintainer wants to update the templated data, can just do 'makepkg --maintainer'.
Users who are paranoid could then add an option in makepkg.conf to /always/ regenerate these sections from their local copies, or maybe only regenerate using the same version of that module.
The important part about this way of doing things, is from an end users perspective, its identical, except for the additional strange guard-comments.
The only really big downside I see to the approach is the commenting stuff is a little bit magical.
Allan
TLDR Version of all that:
1. Instead of lots of copy-paste from known examples .... 2. We write markers where things would appear 3. stuff understands those markers 4. makepkg copy-pastes for us 5. ..... possibly with a little bit of automation/processing in the middle 6. the file "remembers" that we copy-pasted, just enough that you could "re do" the copy-paste at a latter time 7. makepkg can control when the latter time is, and can re-do- the copy-pasting.
On 07.12.2012 04:46, Kent Fredric wrote:
Maybe the "Arch" way would be more template based, and maybe it could have a sort of "guard region comment" combined with some automatic content regeneration, ie: https://gist.github.com/4230499
That's a lot better and I really like the idea of simpler cpan pkgbuilds.
Users who are paranoid could then add an option in makepkg.conf to /always/ regenerate these sections from their local copies, or maybe only regenerate using the same version of that module.
We'd have to ship all old versions of the templates for regeneration of the same version to work, but I guess it is a good idea anyway.
I also think that makepkg should always regenerate the template if its version is available just to be sure. People are almost certainly not going to verify the code given it will probably also grow larger to handle corner cases.
At the very least it should check if the code differs from the template and abort to prevent someone from applying fixes that will get lost later. Either fix the template or don't mark it as being part of one.
The only really big downside I see to the approach is the commenting stuff is a little bit magical.
You could go with something like: # template start: name=perl-module; sha1=feedbeef42c0ffee; version=1.2.3 code code # template end
(In case it isn't, the comment should be on one line)
That's pretty easy to parse for both a human and a script and also tells a new user that the code is a template without requiring any weird syntax.
On 08/12/12 03:17, Florian Pritz wrote:
You could go with something like: # template start: name=perl-module; sha1=feedbeef42c0ffee; version=1.2.3 code code # template end
On 07/12/12 13:46, Kent Fredric wrote:> 3. #<<NAMEHERE>> is replaced with #<NAMEHERE:sha=$sha1:v=$version> (
where $sha1 is the sha1 of the content that was inlined, and $version is the version of the module that was used to generate the body. 4. generated content is injected after modified #<<NAMEHERE>> 5. closing #<<-NAMEHERE>> comment is added.
I'm going to give this idea the OK to go into makepkg...
However it would be good to come to some agreement on the syntax first. In particular, I'd like to see the syntax and the sed/awk line that would be used to replace it on first use and update it subsequently. Remember that there could be nesting. Once that is demonstrated and the final format chosen, then it can be implemented.
I am picky about this because we do not like breaking PKGBUILD formats in the future and I do not want this to become the maintenance nightmare that it could end up being if done wrong.
On 11.12.2012 14:47, Allan McRae wrote:
On 08/12/12 03:17, Florian Pritz wrote:
You could go with something like: # template start: name=perl-module; sha1=feedbeef42c0ffee; version=1.2.3 code code # template end
On 07/12/12 13:46, Kent Fredric wrote:> 3. #<<NAMEHERE>> is replaced with #<NAMEHERE:sha=$sha1:v=$version> (
where $sha1 is the sha1 of the content that was inlined, and $version is the version of the module that was used to generate the body. 4. generated content is injected after modified #<<NAMEHERE>> 5. closing #<<-NAMEHERE>> comment is added.
I'm going to give this idea the OK to go into makepkg...
However it would be good to come to some agreement on the syntax first.
Any progress on this?
On 02/02/13 23:48, Florian Pritz wrote:
On 11.12.2012 14:47, Allan McRae wrote:
On 08/12/12 03:17, Florian Pritz wrote:
You could go with something like: # template start: name=perl-module; sha1=feedbeef42c0ffee; version=1.2.3 code code # template end
On 07/12/12 13:46, Kent Fredric wrote:> 3. #<<NAMEHERE>> is replaced with #<NAMEHERE:sha=$sha1:v=$version> (
where $sha1 is the sha1 of the content that was inlined, and $version is the version of the module that was used to generate the body. 4. generated content is injected after modified #<<NAMEHERE>> 5. closing #<<-NAMEHERE>> comment is added.
I'm going to give this idea the OK to go into makepkg...
However it would be good to come to some agreement on the syntax first.
Any progress on this?
No... I expected to see a wiki page started with the details of how this would work and some examples.
Allan
On 03.02.2013 00:07, Allan McRae wrote:
On 02/02/13 23:48, Florian Pritz wrote:
Any progress on this?
No... I expected to see a wiki page started with the details of how this would work and some examples.
I don't speak awk so I coded a basic POC in perl. If someone wants to turn this into awk please be my guest (assuming everyone is happy with the behaviour and input + output).
It updates an input containing either "# template start; .." and "# template end; ..." markers or "%% template input; .." with the current templates. The "%% template input" syntax is just for initial PKGBUILD creation so the user doesn't have to write a start and end tag with no code inbetween.
Perl script: http://paste.xinu.at/SMlb/ input file: http://paste.xinu.at/Fue8s/ template files: http://paste.xinu.at/tVhDo/ http://paste.xinu.at/y7x4S/
Example output: ###### pkgname=foo pkgver=1
build() { # template start; name=perl-module; sha1=TODO; version=TODO; this is before the blabla template # template start; name=perl-bla; sha1=TODO; version=TODO; bla bla # template end; name=perl-bla and this is after perl Makefile.pl make make install # template end; name=perl-module } ######
If you run the script again it will remove the inlined templates and recreate them from the template files.
Another note: Lukas suggested on IRC that we could also just use an existing macro tool such as m4. I didn't think about it before, but I feel like an inline solution that just updates a simple file is better suited for PKGBUILDS since they tend to be rather small and can be viewed more easily if everything is inlined. Any other opinions here?
Florian
On 23/03/13 04:34, Florian Pritz wrote:
On 03.02.2013 00:07, Allan McRae wrote:
On 02/02/13 23:48, Florian Pritz wrote:
Any progress on this?
No... I expected to see a wiki page started with the details of how this would work and some examples.
I don't speak awk so I coded a basic POC in perl. If someone wants to turn this into awk please be my guest (assuming everyone is happy with the behaviour and input + output).
It updates an input containing either "# template start; .." and "# template end; ..." markers or "%% template input; .." with the current templates. The "%% template input" syntax is just for initial PKGBUILD creation so the user doesn't have to write a start and end tag with no code inbetween.
Perl script: http://paste.xinu.at/SMlb/ input file: http://paste.xinu.at/Fue8s/ template files: http://paste.xinu.at/tVhDo/ http://paste.xinu.at/y7x4S/
Example output: ###### pkgname=foo pkgver=1
build() { # template start; name=perl-module; sha1=TODO; version=TODO; this is before the blabla template # template start; name=perl-bla; sha1=TODO; version=TODO; bla bla # template end; name=perl-bla and this is after perl Makefile.pl make make install # template end; name=perl-module } ######
If you run the script again it will remove the inlined templates and recreate them from the template files.
Looks fine. But we either need to get makepkg completely split up, or this needs to be bash based.
Another note: Lukas suggested on IRC that we could also just use an existing macro tool such as m4. I didn't think about it before, but I feel like an inline solution that just updates a simple file is better suited for PKGBUILDS since they tend to be rather small and can be viewed more easily if everything is inlined. Any other opinions here?
Can m4 update? It is also a pain with escaping from memory.
On 23.03.2013 00:13, Allan McRae wrote:
On 23/03/13 04:34, Florian Pritz wrote:
[....]
Looks fine. But we either need to get makepkg completely split up, or this needs to be bash based.
The perl script is just a prototype, I'm sure it isn't too complicated to rewrite in awk (for someone with awk experience).
Another note: Lukas suggested on IRC that we could also just use an existing macro tool such as m4. I didn't think about it before, but I feel like an inline solution that just updates a simple file is better suited for PKGBUILDS since they tend to be rather small and can be viewed more easily if everything is inlined. Any other opinions here?
Can m4 update? It is also a pain with escaping from memory.
Didn't manage to google anything about m4 being able to update, so I guess it can't.
I remember having read something about the escaping pain, but I don't know any more.
Still waiting for Dave's reply on all those questions here
pacman-dev@lists.archlinux.org