Public SourceMage Discussion List

[Thomas Orgis <thomas-forum AT orgis.org>]

I will just go into a few point that concern me most.

Am Fri, 25 Jan 2013 17:27:54 -0600
schrieb David Kowis <dkowis AT shlrm.org>: 

>  1. Declarative spell config
>  6. Single spell file

I am not necessarily for a single spell file. I think it is a strong
trait that some files that are most logically expressed as simple bash
scripts, are indeed expressed in that way. Plus: Spells look simple
when they are simple (scripts missing because defaults used). If it's
done right, I'm also not particulary against a single file ... what I
wonder is how well declarative config works with keeping things as pure
Bash that need to be that way (we won't invent another language for
that, right?).

But I put strong support into the declarative config corner: PREPARE,
CONFIGURE, DETAILS and DEPENDS really, really, should be declarative,
and combined into one file at that (perhaps you meant only these files
to begin with?) Sorcery needs to work with that information. We do
multiversion support via hacking DETAILS. Well, that would not work
without explicit sorcery support for the declarative syntax, but it
does not really work right now anyway. $(gaze versions $SPELL) does not
work for that, for example. Also, working with DETAILS through Bash is
painfully slow. A simple variable=value parser would be enough for the
basic spell. Question is if it would be faster when written in Bash,
but at least a declarative syntax would open the possibility to write
tools for spells with other languages (be it C, even*).

But, even if it were efficient: Spells hacking DETAILS with Bash
scripting are scary for the folks who didn't start this. They are hard
to maintain, and they keep side-stepping the question if Sorcery should
support multi-version spells ...

Spells that consist of CONFIG and optionally PRE_BUILD/BUILD, INSTALL,
FINAL, if needed, would work for me. Perhaps one could condense the
optional scripts, though.

You skipped that one in the list, didn't you?

> * Have a chroot-based build process, isolating dependencies, as well as
allowing repeatable builds easily.

You line out a possible goal for repeatable and controlled casting and
I'm down with that. A main gripe of mine is a sub-aspect of this:
Isolating the casting from the running system so that one can later
choose to actually merge any changes into "/". This shares the goals of
isolating spell install scripts and catching stupid things with the
chroot points you raised, but my emphasis is on the scenario of a cast
needing to dispel an earlier version of the spell before building the
new one. This is nasty breakage right now with some large packages that
I cannot use while the long build is running. Solution is some isolated
environment that pretends that the earlier version is not present, or
just generally, caches the file system operations that are to be done
for some casts until the next merge. I just wanted to phrase this
explicitly before we implement some funky chroot casting that manages
to miss the point;-)


Alrighty then,

Thomas

* People who know me know that I actually mean Perl;-)

Attachment: signature.asc
Description: PGP signature