Public SourceMage Discussion List

[Flavien Bridault <f.bridault AT fra.net>]

Le mercredi 10 août 2005 à 09:39 -0700, Seth Alan Woolley a écrit :
> On Wed, Aug 10, 2005 at 11:15:46AM +0200, Flavien Bridault wrote:
> > Le jeudi 28 juillet 2005 à 08:22 -0700, Andrew a écrit :
> > > > 
> > > > On a different tangent, in the example PRE_BUILD, you have:
> > > > 
> > > > unpack_file ''
> > > > 
> > > > Is that correct?  Shouldn't there be something else on that line, 
> > > > like a 
> > > > reference to the file?  If not, then shouldn't the two single quote 
> > > > marks be 
> > > > removed?
> > > > 
> > > 
> > > Yes actually that is correct. unpack_file's parameter is the n part of
> > > SOURCEn. By convention we count SOURCE SOURCE2 SOURCE3 ... so the first
> > > value is the empty string. The function uses the parameter to expand
> > > the various SOURCE, SOURCE_URL and SOURCE_GPG values.
> > > 
> > > It is true that in bash an uninitialized variable is the empty string so
> > > you could remove the quotes and it would still work, just style I think,
> > > not that gurus have to adopt our suggested style.
> > > 
> > > David, can the doc be updated to include more explaination on 
> > > unpack_file?
> > > I think maybe if theres a second real source in a spell, "unpack_file 2"
> > > could be used and it would be more obvious than an oddly place ''.
> > > 
> > > -Andrew
> > > 
> > > 
> > 
> > Sorry for coming so late in the discussion, but I only read the
> > documentation now. I'm always afraid about GPG, I don't know why... :p
> > 
> > I just have two remarks about the extra development needed to get a
> > spell working with GPG checking. I guess all of the design have been
> > discussed during a long time, but I didn't participate in the
> > discussion, so these are kind of 'newbie' remarks ;-)
> 
> Fortunately, you only have one comment (meaning the other eight ways to 
> use the API are ok), and it's something I think I had a good reason for:
> 
> > 
> > First, in a effort of getting as simple as possible, the :
> > SOURCE2_URL=${SOURCE_URL}.asc 
> > SOURCE2_IGNORE=signature
> > 
> > is not really straightforward. Why not have a SOURCEn_SIG instead, as we
> > have a SOURCEn_GPG ? I'm sure there is a good reason for it, but from a
> > 'user' point of view this is really not obvious. 
> 
> SOURCE2_IGNORE=signature forces the system to no-op (be silent) if you 
> run unpack on SOURCE2.  The system is designed to be easily auditable.  
> unpack_file isn't needed for signatures, but in order to audit the 
> spellwriters' use of unpack_file, I want to check to see if unpack_file 
> is not being used at a time when it should be used.  
> SOURCE2_IGNORE=signature is just a signal to me (even though sorcery 
> doesn't actually get to parse it most of the time) that it should be 
> ignored.
> 
> To answer your question on why not SOURCEn_SIG instead, there is 
> SOURCEn_IGNORE={volatile,unversioned,signature} so you can specify a 
> reason to ignore it.  Furthermore, what would I put in SOURCEn_SIG?  
> SOURCEn_GPG is where you "already" point to the signature.
> 
> And I didn't want to rely on any assumptions, so I didn't assume there 
> would be a SOURCEn+1_anything anywhere.  I wanted to let the spellwriter 
> have control over the order things were downloaded and what was used 
> where.
> 
> > 
> > Then, the extra work that should done in PRE_BUILD seems also useless.
> > Would it be not possible in sorcery that if SOURCEn_SIG and SOURCEn_GPG
> > are detected, that this new unpack function would be automatically
> > called ?
> 
> It's already automatically called in sorcery.  If it detects the old 
> API, it automatically falls back to the old API.
> 
> Like the old API, unpack_file is only called for the first source.  For 
> later sources it is not called, however it could be changed to be 
> automatically called on all defined contiguous SOURCEn's as a possible 
> improvement, and that's been something I've been considering, but I 
> wanted to keep the number of changes in behavior down to a reasonable 
> level.  I expand on this below.
> 
> > 
> > What really afraid me is that all gurus convert all their spells, and
> > that, six months later, a API change is decided and all this extra stuff
> > would become obsolete. And I don't have to explain how painful the API
> > changes are. ;-)
> > I obvioulsy understand that what I propose could not be done in two
> > hours, 
> 
> Automatic calling can be done in two hours easily. It would just make it 
> call unpack_file on all SOURCEn's similar to what summon does, however, 
> because it _will_ fall back to the old API (the new API is designed to 
> be safe to call on all SOURCEn's because this was a possible improvement 
> I was thinking of doing down the road), it could be a bit risky in the 
> case that somebody specified multiple sources but does not have a 
> PRE_BUILD file in use (they could have used unpack() in BUILD instead).  
> At the risk of breaking spells, I think we should wait to add this until 
> all unpack() is removed from spells (anywhere) and we can finally get 
> this deprecated function and the old API removed.  On the converse 
> angle, all unpack_file() calls _should_ be in PRE_BUILD or we need to 
> have a PRE_BUILD defined that overrides the change in the 
> default_pre_build that would be made on all existing spells before I 
> would be satisfied nothing "in theory" would break.
> 
> So, I can craft a criteria statement:
> 
> Once all spells that have no defined PRE_BUILD do have no more 
> references to unpack() or unpack_file anywhere, we can safely add 
> automatic unpack_file calling on subsequent SOURCEn's.
> 
> > but this would *really* be better to remain as simple as possible
> > at the beginning, so that nobody would like to change it later.
> 
> I hope I didn't open up a can of worms here :)
> 
> Seth
> 
Thanks for your answer, Seth, there were obviously some things that I
didn't well understood (I thought there were a .gpg file and a .sig
file, etc... ^_^ ).
Now that I have begun to test those stuff in p4, it is much more
clear. :-)
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss
-- 
-- -- -- -- -- -- --
Flavien Bridault
Source Mage GNU/Linux - Disk Section Guru

irc: vlaaad
jabber: vlaaad AT amessage.be

Attachment: signature.asc
Description: This is a digitally signed message part