Skip to Content.
Sympa Menu

sm-discuss - [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: Seth Alan Woolley <seth AT positivism.org>
  • To: disk AT sourcemage.org
  • Cc: sm-discuss AT lists.ibiblio.org
  • Subject: [SM-Discuss] Response to Flavien's GPG questions, was Re: Spell GPG Checking Book Page
  • Date: Wed, 10 Aug 2005 09:39:33 -0700

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




Archive powered by MHonArc 2.6.24.

Top of Page