[pacman-dev] code reuse for PKGBUILD

[Kent Fredric]

On 7 December 2012 16:46, Kent Fredric <kentfredric at gmail.com> wrote:

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



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