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