[pacman-dev] code reuse for PKGBUILD

Kent Fredric kentfredric at gmail.com
Thu Dec 6 22:46:32 EST 2012


On 7 December 2012 15:32, Allan McRae <allan at 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
>
>
>


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


More information about the pacman-dev mailing list