Public SourceMage Discussion List

[Jaka Kranjc <smgl AT lynxlynx.info>]

On Sunday 27 of January 2013 15:29:43 David Kowis wrote:
> On 1/27/2013 2:55 PM, Jaka Kranjc wrote:
> > On Friday 25 of January 2013 17:27:54 David Kowis wrote:
> >> /.../
> >> A bit more detail on the individual items:
> >> 
> >> Single spell file:
> >> ------------------
> >> Opening 6 files is difficult. Opening one file is easy. I can maintain a
> >> much better context regarding what my variable names are, and what I'm
> >> going to do with them. There's no reason we *must* split things up into
> >> many files, and I don't think there's any benefit to it. I believe this
> >> is a change we must implement.
> > 
> > The vast majority of spells are very short and simple automations, so I
> > find your reasoning and maybe ignorance absurd. Consider using an IDE if
> > you really have problems.
> > 
> > The bad aspects were already outlined, so let me just mention that the
> > inheritance we use could be adapted, but it would all be at a cost to
> > clarity and scriptability (quill would also need a rewrite).
> 
> Not all spells are so simple. It gets much more complicated when one
> tries to deal with multi-version spells, or packages with complex
> sub-dependencies. It would be significantly easier to open only one
> file, than it it to open six, especially when shelled into a box using
> vim. I believe that people efficiency is important, and I would rather
> us change the way that we do things than provide a solution that is "Go
> use an IDE, if you don't like it."
So you'd radically change everything due to a minority of spells?

I have no idea if I am representative, but I have no problems with editing 
complex spells with less/nano (you do know you don't have to open each 
manually?). A powerful IDE like vim should be even less problematic. Quill 
simplifies the process even further.

Imagine the linux spell in one file. :>

> >> Well defined binary package format:
> >> -----------------------------------
> >> Our ISO is insanely difficult to generate, because we have no binary
> >> packages at all. We have no way of bootstrapping a system. We've had
> >> attempts at this in the past with official chroots, but there was never
> >> a particularly repeatable way to generate them. I want to make a smaller
> >> Core grimoire that we do provide binary packages for that can be used to
> >> build a completely new system. Not enough to install all of KDE or
> >> whatever, or even X, but a booting system that you can log in to, and
> >> start building your own packages. To do this, we need a binary package
> >> format that can be acquired, verified, and examined easily. I need to
> >> know how the package was configured, when it was built, and of course, I
> >> need the files to install. This is also necessary for building an ISO.
> >> Acquiring and extracting a known config for a spell to build the
> >> official ISO is necessary to have repeatable, reliable ISOs. As well,
> >> this enables sharing of built packages across many machines easily,
> >> especially if they're all built the same way. The binary package format
> >> will need to contain enough information to be able to verify the config
> >> of the binary package, and compare it to what was requested to be built.
> > 
> > What's actually missing now? We store most of the state that was used when
> > the spell started casting and you can even have config.log appended to
> > the compile log (which is external, I know). Reuse is as simple as
> > unpacking it, exactly what resurrect does.
> 
> They're stored separately, and not tied together. We're like 90% of the
> way there, yes. I would just like to be able to
> distribute/share/whatever one file with the config and such tied to it.
Why not just extract it into a separate tarball et voilà!? Otherwise you need 
to define some nicely parsable new format to hold this diverse data and 
converters to and from it.
 
> > How would it be versioned/developed? I guess it would replace
> > stable/rc/test and all the others would remain in what currently test is.
> 
> It would be separate from the existing stable/rc/test setup, and we
> could define a different workflow for it, when we update it and such.
> And spells would have to meet certain criteria in order to be accepted
> into this grimoire. Everything else would go in the existing grimoires
> as they are, making it easy for things to be kept up to date for people
> that want them updated while giving us a solid core grimoire that's
> stable and reliable.
Works for me. If this chroot chicken and egg loop is cut, we should be able 
to 
do it with just one permanent branch without loss of quality.

> >> Declarative spell config:
> >> -------------------------
> >> Spell configuration needs to not be procedural. I should be able to say
> >> "cast kde" and get a menuconfig style interface where I can toggle
> >> things off and on and know what the effects of my selections are going
> >> to be without having to restart the entire process again. I should also
> >> be able to store a config to a file "Dave's KDE Desktop Config" and load
> >> that in, and be notified of new options somehow. This is critical not
> >> only to making it easier for people to construct systems, but to have
> >> repeatable builds. When someone complains that their package doesn't
> >> build, we can ask for their config, throw it in a chroot, and duplicate
> >> the problem, either finding a patch, or finding out that their config is
> >> simply broken. Finally, having stored configs allows us to package those
> >> up with a binary package, and should you already have a binary package
> >> with the proper config, you can just extract that rather than rebuild it
> >> again.
> > 
> > Configs are already stored, extractable and reproducible.
> 
> And reloadable? And I can update a spells config, and know what options
> have changed, even within if/then logic? No, that's not possible.
For the few that have nested logic, no, you'd only know about what you 
changed 
directly.
 
> > As for the declarative part, some solution to be able to see and set
> > everything up front would definitely be cool. Especially for any test
> > scripting without Expect.
> > I don't see a way to make it completely declarative though, unless you
> > leave the dependency resolution out of it or (re)generate all the
> > possible trees. :S
> It'd be work to generate the possible trees, but I think it'd have
> advantages, as I've detailed in other mails.
The number of permutations would make a parallelized C app cry, let alone 
bash. Think about people that update seldomly or when you cast xorg-server or 
some DE for the first time — hundreds of spells get pulled in.

LP
-- 
To err is humor