On 7 December 2012 16:46, Kent Fredric <[email protected]> wrote:
> On 7 December 2012 15:32, Allan McRae <[email protected]> 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
