What next?

George Makrydakis gmlistbox at obsethryl.eu
Wed Feb 27 15:29:05 PST 2008

On Wednesday 27 February 2008 23:44:11 Jeremy Huntwork wrote:

> And judging by the recent lull in community discussion/interest followed
> by this flurry of activity, it's clear to me that something can and
> should happen, if LFS is going to continue.

First of all, I will try to be an advocate of what you don't wish to see 
(perhaps, feel free to correct me if I am wrong). IF you are to reply, reply 
in a meaningful manner, else don't. Since I would like a serious reply on 
this particular subject:

In what way(s) could you do this that diy-linux and clfs do not do already? 
How is it going to compete with the other two? Or three.. Or four... Or 

> > * combine the resources/knowledge of the various projects into something
> > more coherent,

> Agreed.

Combining from the other projects? How? Why? They already _have_ it combined. 
Why not work on _merging_ the communities into a single project? Doesn't that 
make more sense since the goals are apparently the same since you are 
choosing an evolutionary approach for LFS ?

> > * Implement PM (Oh yes, oh yes)
> Agreed. But as has been noted we need to be careful and deliberate about
> how we approach this one.

Implementing a _really_ good package manager is not an easy task. This is why 
there are so many of them. After you have studied them collectively and 
figured out the reasons for their incompleteness, you can discuss about what 
to do. To date and from the archives, no discussion like this has ever taken 
place in a meaningful manner, and stand - alone projects took their own path 
and evolved into different self - hosting communities.

Isn't it a weakness in the social structure of LFS that it could not hold 
these resources together? Educational use is no excuse imvho.

> > * Move away from the manual cmmi to an automated build system (Sounds a
> > bit like Gentoo)
> Not sure. As has been brought up, education is key and we don't want to
> lose that. In fact, we want to improve on it and steer clear of a
> 'Gentoo path'. However we approach automation and package management
> needs to take that into heavy consideration. We're going to need to
> really discuss how this is all actually set up.

Again, how can it be different from Gentoo, Sourcemage, T2, clfs, diy-linux, 
Archlinux, GoboLinux etc... the list is endless on the meta - distribution 
front. Package management is not going to help saving, if at all, anything.

> > * Make the LFS book more informative and less "techy/geek" speak.
> +57 (I can have 57 votes, right?)

I do not think it is geeky, it should be more "geeky" because there are MORE 
THINGS TO LEARN than how to build a toolchain, but i am a "bystander" who has 
no reason to doubt your intentions and is probably unimportant to you as a 
contributing opinion (for the time being, as some other people, I do not like 
some of your policies when it comes to "combining" things so there is really 
not much to contribute *here* but an opinion).

> This, IMHO, should be the main thrust and focus of the change. Yes, the
> above three items are vital to keeping LFS usable and growing, but not
> without this core component. The goal should still be to _teach_ and not
> just dispense information. Trust me, there is a difference.

Aren't there projects doing that, isn't this the reason for the original 
split? Again, in  *what*  way(s) could LFS be different?

> > I keep coming back to education... That was the goal of LFS and should
> > continue to be it's overriding objective.
> Yep yep yep yep yep, uh-huh uh-huh.

Then why does it need to evolve the "non - educational" aspects?

> For example, if we are merging efforts between the sub-projects, what
> form does LFS now take and how is it arranged organizationally? Also, on
> the topic of form, what changes to the structure of LFS will make it
> both _more_ educational (again, think _teach_, not just list facts) and
> easier to provide PM and automation? (Even those aspects should be
> looked at from an educational standpoint.)

Merging efforts (no matter to what you are referring to, you have a point). 
Now this is the first and only thing that should be really considered. I read 
that Mr. B You are absolutely correct on this one. Would you care to explain 
if you are actually referring to attempts like LeafOS (you and a couple of 
people where doing this long time ago, but it never lifted up), how things 
should be done so that they do not end up in a standstill?

As to automation, package management ... give it a couple of days... Really. 
You are hardly expecting this. Hardly. You will have much to discuss about 
this in the following days. MUCH. And you will understand why some things
developed patiently and unannounced before they ripe, create "glue points".

> With a bit more of a solid proposal, we might be able to move away from
> just discussions and begin on a LFS-NG or, at least, a POC for LFS-NG.

On the other list, the project founder has discussed about killing LFS the way 
it is first.

To me, the only issue that is holding back LFS and fragmenting it, is its 
social structure. You are unlikely to have LFS-NG without taking into 
consideration this factor. Until you do, you will be bleeding out people 
elsewhere, or trying to "combine" things into branches etc. Other projects 
are not supposed to be component or conceptual supermarkets.

Good Luck.

> --
> JH


More information about the alfs-discuss mailing list