Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Response to Flavien's GPG questions, was Re: Spell GPG Checking Book Page

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Flavien Bridault <f.bridault AT fra.net>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] Response to Flavien's GPG questions, was Re: Spell GPG Checking Book Page
  • Date: Thu, 18 Aug 2005 16:36:06 +0200

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




Archive powered by MHonArc 2.6.24.

Top of Page