Defining ALFS and it's initial goals. (was Re: Fwd: Re: Moving on)

Jesse Tie Ten Quee highos at highos.com
Sat Jun 16 18:47:16 PDT 2001


Yo,

On Sat, Jun 16, 2001 at 12:45:06PM -0400, Gerard Beekmans wrote:
> Let me make one thing clear: our initial goal won't be to be a
> ultra-compatible package management like you said, but we all know Linux
> world lacks this, it's needed, and needed badly. But there's so much
> work we should concentrate on it after we get a base going. But since we
> use the right stuff (XML that is), it'll be easy to expand ALFS into
> that goal and other goals.

Ok, lets get this all in the open and get a list of _initial_ goals that
ALFS is going to tackle.

Read that again, i said "initial goals", that is, the goals that we need
to get done in the here and now, things we need to start with, to build
on, things we can get done inside of a month if we work at it.

"At the heart of ALFS you will find the so called alfs-profile. This
profile is written in XML and determines the shape of the system being
built. By feeding the ALFS tool different profiles you will end up with
different kinds of systems."
    - ALFS website, introduction.

Now, after reading that and thinking of what needs to get done initially,

    o Fixing up/cleaning up the syntax.
    o Writting a DTD for the XML profile syntax.
    o Documenting that syntax.
    o etc...

We can't go forward without these simple things done, right?

Now, long term goals will always be adding all the jazz, that is,
Package Management Support, multiple fe/be implementations, IPC/RPC, etc

But perhaps we are starting to big, perhaps we need to refocus on what
exactly ALFS is at the core, an alfs profile, and write a simple
all-in-one ALFS implementation (or tool if you will) (like what is ALFS
CVS module right now) that once given the profile will install a package
or system.

If we do that, we have somewhere to start, somewhere to build from,
instead of adding everything from the start, which i think is just going
to cause confusion at this point.

This started to make me thing think after i read a comment Simon posted,
what exactly are we doing? are we creating a complete solution from the
get-go? (aka a distrobution)  or a framework that we can build on?

We can still create a complete solution, but we need something to build
on, right now id prefer to concentrate on building a framework, da?

This also started to make me thing about the different ALFS
Implementations that are going to show up in the future, we are going to
write a desgin doc, yes?  what should be included in that design doc
initially?

Going with IPC is problably over kill right now, as is having multiple
applications (frontend/backend) or it being network-aware.

Maybe we should keep it KISS and define how an implementation, even if
it's a single application, needs to parse the profile and get the work
done.

-

Now, even if we didn't focus on package management from the get-go, it
would not be that hard to add it to the profiles once we have completed
the initial goals. (or at least have them in a working state)

Let's take ed, your basic LFS package and look at the package;

<package>
    <name>ed</name>
    <version>&ed-version;</version>
    <unpack>
        <archive>&packagesDir;/&ed-package;</archive>
        <dest>&buildDir;</dest>
    </unpack>
    <config>
        <configure>
            <dir>&buildDir;/&ed-dir;</dir>
            <param>--prefix=/usr</param>
        </configure>
    </config>
    <build>
        <make>&buildDir;/&ed-dir;</make>
    </build>
    <install>
        <make>
            <dir>&buildDir;/&ed-dir;</dir>
            <param>install</param>
        </make>
        <move>
            <src>/usr/bin/ed /usr/bin/red</src>
            <dest>/bin</dest>
        </move>
    </install>
    <remove>&buildDir;/&ed-dir;</remove>
</package>

Now, what is a Package Management System? what does it do? it records
the what, where and when a package was installed (and perhaps even the
how).

That package above isn't complete, we would need to add a few tags i
think, like a <description>, packages it <depends>'s on, for it to even
come close to having package management support.

But.. that's the power of XML, we aren't hard coding anything, we can
always add more tags down the road (which will happen) and i think we
need to ask ourselves do we _really_ need to focus on package management
support this early on? we haven't even got or agreed on a good working
XML profile syntax.

-

Anyways, just some random thoughs after taking a bit of time away from
the keyboard and doing some thinking.

I'm trying to find a direction, which we can focus on and go with, i'm
not thinking long term yet, well i am in some regards, but in my
opinion, we need to build from something, a generic framework, if we
want to add all the 'jazz', so we need to know how far we want to go
from the start.

There's been *alot* of good conversations that have taken place in the
last few days, id like to thank everyone involved so far, it's great to
see you guys are all interested, let's set some initial goals and head
for them... that is, if you guys are satified with going with XML and
ditching the multiple fe/be/ipc support for now and keeping it KISS =)

(Just remenber, the core is the alfs profile, the jazz can always be
added)

-- 
Jesse Tie Ten Quee - highos at highos dot com
-- 
Unsubscribe: send email to alfs-discuss-request at linuxfromscratch.org
and put unsubscribe in the subject header of the message



More information about the alfs-discuss mailing list