Public SourceMage Discussion List

[Seth Alan Woolley <seth AT positivism.org>]

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

-- 
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Quality Assurance Team Leader & Security Team: Source Mage GNU/linux
Linux so advanced, it may as well be magic http://www.sourcemage.org
Secretary Pacific Green Party of Oregon http://www.pacificgreens.org
Key id FDCEE733 = 5302 B414 64C4 6112 3454  E082 99F0 69DC FDCE E733

Attachment: pgpCYcslOdKHB.pgp
Description: PGP signature