Skip to Content.
Sympa Menu

sm-discuss - [SM-Discuss] Teh Future

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: David Kowis <dkowis AT shlrm.org>
  • To: SM-Discuss AT lists.ibiblio.org
  • Subject: [SM-Discuss] Teh Future
  • Date: Fri, 25 Jan 2013 17:27:54 -0600

I took my time in preparing a response to the questions I've received,
not that I've received very many, but I wanted to give enough time for
the community to think about it without being influenced by me.

Anyways, I'll respond to the questions I've received and some statements
in general.

> What's your personal stance on this? Do you think we should work on
> 2.0 or let Source Mage be done and just maintain the grimoire?

I would like to see SMGL continue into the future as a distro that
people love to use, and that is competitive, but I think we'll have to
change things significantly. I'll go into detail on those a bit later. I
don't have nearly the time I used to in the past, and have had to cut
out hobbies and things that I enjoy doing to prioritize the things I
really like to do, and it makes me somewhat sad. SMGL is one of those
things that I somewhat like to do, but has gotten more difficult to do
over time.

I would like to see motivation towards a 2.0 branch of things, where we
break backwards compatibility, somewhat of an internal fork, if you
will. I think that there is a niche that SMGL fills that is a useful one
to have, we just need to improve on how we are filling it, and I believe
that will require breaking the way we do things currently.

> I must admit I really wonder what the 1.0 should stand for.

1.0 means we're done, and we can ship this as something people can use.
It means that we can focus on other things, or that any bugs/feature
requests aren't going to be fulfilled. It's basically owning up to how
we've been treating things for the past year. We've had no new sorcery
releases, only notes added for workarounds for existing bugs, and the
grimoire has just been maintained. Packages are updated, etc.

> Is it the install ISO? At least there should be one when declaring a
> new version.

Sadly, building an ISO is not trivial, it's not repeatable, and all the
work that has gone into building scripts doesn't keep up with
successfully building ISOs for install. This is part of something I
believe we have gotten fundamentally wrong in SMGL, and would like to
see fixed.

=====

Now, on to those things that I would like to see fixed as part of a
Source Mage 2.0 initiative:
At a high level:
* have a single file describing a spell: Combine DETAILS and friends
into one file.
* Have a well defined binary package format that we build to, and use
to install into the system.
* Have a Core grimoire that is well supported and that we provide
binary builds for, for generic configs.
* Build a chroot from scratch using packages from Core.
* Build an ISO from scratch using packages from Core.
* Updated init system
* Have a chroot-based build process, isolating dependencies, as well as
allowing repeatable builds easily.
* Declarative spell config


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.

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.

Core grimoire:
--------------
We need to pare down the amount of stuff that is well supported. We
don't have enough manpower to take care of all the things. The Core
grimoire will provide binary packages of the things we support. Those
configs are what we support. This way we can guarantee that someone will
be able to get a working system fired up based on the configs we've got.
We should have no problem supporting configs for i686 as well as x86_64
eventually, but we can target only one for the beginning.

Chroot from packages:
---------------------
I need to be able to run a script and end up with a chroot that is a
base system for SMGL. Those packages should be sourced from the Core
grimoire.

ISO from packages:
------------------
I need to be able to run a script and end up with an ISO containing
enough stuff to install a new system. Those packages need to come from
the Core grimoire.

Updated init system:
--------------------
Simpleinint-msb works, but it's old and crappy. I'm a fan of systemd,
because it makes things amazingly easy to do, and is ridiculously fast.
It's also been adopted by several linux distros, and large projects.
However, that's not set in stone, we just need something newer, and
preferably something that other distros are using, so we can take
advantage of the work that others are doing as well.

Chroot based build process:
---------------------------
For building binary packages, I want to take advantage of a chroot and
unionfs (or rsync and hardlinks or something.) Inspiration from this
page:
https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot
It's probably the sanest way to produce a package that we can ensure
isn't melding in dependencies we don't want and such. By ensuring that
we build things into binary packages as well, we can catch leaky
installs, or missing dependencies when we're building the chain of
packages. Additionally, it'll give the system itself protection from a
stupid installer doing bad things, or a partially failed install.

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.


That's my brain dump of high level things I think SMGL needs to
accomplish to remain relevant in the world of Linux Distros. I can't
promise that I have time to do all these things, as I don't really. I
can help with planning, and I can help with direction, but I will need
others to step up and help start with the design of these things.
In order of importance:
1. Declarative spell config
2. Binary package
3. Chroot generation
4. ISO generation
5. Updated init
6. Single spell file (although, I think this basically happens if we
implement declarative spell configs)

Doing the things in this order gives us clear goals, and we can then get
onto shipping ISOs, and it will make it significantly easier for people
to start using the distro, as well as easier for us to continue to use
the distro and build/maintain packages.

Or we can leave it at 1.0 and be done, moving on to different things.

--
David Kowis

Attachment: signature.asc
Description: OpenPGP digital signature




Archive powered by MHonArc 2.6.24.

Top of Page