Public SourceMage Discussion List

[David Kowis <dkowis AT shlrm.org>]

On 1/27/2013 6:16 AM, Thomas Orgis wrote:
> 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*).

I don't mind what language we write it in. I think bash is not
particularly well suited. Bash is excellent for tying programs together,
so maybe we write our programs in something other than bash, and use
bash to tie them together? Not sure how that would shake out. I would
like to use a language designed for writing software, rather than a
shell, since we are building software to build software. (yo dawg)

> 
> 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?

I'd be more tolerant of keeping them as individual files if they were
independent. The spell files, however, are not independent. They are
exceptionally interdependent. We create variables in one, and reference
them in others. They're tightly coupled, in general. Perhaps splitting
configuration from installation, but then we've only got two, and even
then we'll need to do some checks to know how it's configured depending
on certain installation logics. I don't believe they're separate files
in anything other than logical organization on the disk.

> 
>> * 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;-)

Well, if we build in a chroot, we can ensure that the chroot does not
contain the earlier version of the spell during the build/install
process. If we do things where we package everything into a binary
tarball first, we will do the installation into the real system outside
of anything that might affect the build/install of the package itself.
Potentially as simple as `tar -xJf`. That might rectify the problem you
describe entirely.


Thanks for your thoughts,
David Kowis

Attachment: signature.asc
Description: OpenPGP digital signature