Automated Linux From Scratch development discussions

headers lfs lfs | 8 Feb 2008 17:20

--

-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

On Fri, Feb 8, 2008 at 8:20 AM, lfs lfs <linuxfromscratch <at> yahoo.com> wrote:
> /bin/sh: makedepend: command not found

You need the makedepend command from the Xorg utilities. It needs to
be in your PATH, too.

--
Dan
--

-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Alan Lord wrote:
> Firstly, Gerard is definitely on the right track in his recent posts, 
> and DJ also hit the nail on the head too with some of his concerns.

Based on the sorts of replies I've been seeing most of us are agreed 
that LFS needs a change of direction. Something that will make it more 
useful as an end product and not _just_ a one-time learning experience.

Allowing greater end usability in this way is also sure to stir up more 
interest from both those long associated with the community, and those 
just joining.

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.

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

Agreed.

> * 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.

> * 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.

> * Make the LFS book more informative and less "techy/geek" speak.

+57 (I can have 57 votes, right?)

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.

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

> So perhaps the LFS project becomes some sort of "course" (And I use the 
> term loosely). The "modules" of which, could be something like:
> 
> * Learning the basics (Command Line, cmmi, security, toolchain, blah blah)
> * Scripting/Automating (A subject about how LFS get built, the tools, 
> the process etc)
> * Basic Useful Applications (A sort of mini BLFS where we get 
> networking, X and maybe Firefox/TB type apps installed)
> * Building your Distro (Completing the core build-out adding your chosen 
> apps and utilities and configuring)
> * Making it your Distro distributable (How to make a liveCD or "your 
> distro", how to make an installer script...)

This is a good start, I think. What I would like to see happen is for 
Gerard to layout a proposal of core changes (perhaps based in part on 
the above suggestions) with a little more detail than he has given so far.

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.)

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.

--
JH
--

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

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

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

...
--

-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Instead of just reading the conversation, I'd like to
add to it.  These ramblings are from someone who's
linux lineage looks like this:

Mandrake --> Suse --> Gentoo --> LFS --> Ubuntu

That spans a mere 5 years.  Of those distributions,
Gentoo and LFS were the most instrumental in shining
light into the dark corners of the OS.  And of those
two, LFS was the MosT educational by far.  That was in
fact the reason I spent 6 months on it.

Specific thoughts:

Although I managed to build LFS/CLFS with other
distributions, I always preferred the LFS LiveCD.

It seems in the previous LiveCD topic that the general
opinion is that the LiveCD should be built strictly
per the LFS manual.  I do not understand how this is
possible, as there is a difference between an OS
running from harddisk and one running from LiveCD or
LiveUSB.  My preference would be LiveUSB, as I don't
have to throw away so many CDs.  Just my two cents on
that topic.

The only thing keeping me from using LFS/CLFS as
fulltime/all-the-time learning distribution is that it
has not adopted a package management system whether
simple or complex.  And what I am personally keenly
interested in, is how you build a distribution from
scratch while integrating a package management system.

Other magic that occurs which I would like to
understand is how 'we' develop/identify the patches
which the normal user such as myself applies blindly. 
I am specifically curious about this process.

Lastly, I express thanks to those running the main and
subprojects and all the other 'invisible' folks that
toil away on their labor of love.  Your work has been
instrumental in helping me learn how an OS is put
together from pieces.

Best regards,

Harvey

George Makrydakis wrote:
> 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 
> Infinity?

I'm sorry for being dense, but I'm not sure I understand what you're 
asking here.

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

Unless I misunderstood Gerard's proposal, that is what he is suggesting. 
We don't have (seemingly) the manpower and community interest any more 
to keep the current structure in place. I think the projects would have 
to be merged in order to continue.

[snip]

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

Very probably. And part of the issue, I think, has always been that 
different people see LFS from different viewpoints. This will always be 
the case to a certain extent, but perhaps, with a redesigned project, 
the potential for social problems can be taken into consideration as 
part of the re-design.

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

How it will be different is something that will have to be discussed.

> 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).

I don't know what you refer to when speaking of 'policies for 
combining'. In any case, many of former LFS "policies" are probably moot 
at this stage, due to the recent heavy stagnation.

[snip]

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

I doubt many people here were aware of the existence of LeafOS. But, 
since you bring it up, it is a shame that it didn't achieve its goals. 
It failed mostly because on a personal level, I didn't any longer have 
the consistent time to give it.

Anyway, LeafOS only existed because LFS did not seem to be moving 
forward or doing much of anything, really. And now, much of what is 
being discussed on the LFS lists are core concepts and goals of the 
abandoned LeafOS project. I would have preferred for it to happen with 
LFS in the first place, so I am happy now to hear these suggestions.

> ---------------------------------------------------------
> 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".
> ---------------------------------------------------------

Of course. I still have a few suggestions and ideas to put forward, but 
I am holding back a lot on these threads, because I'm waiting to see how 
the community as a whole responds first. And, I want to see Gerard take 
active action to make the decisions happen - to show that he is serious 
in reanimating the project, instead of just talking about new ideas.

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

You may be right that the social structure needs help. Suggestions on 
what needs fixing would be helpful, although, you may find that things 
which bothered you previously about LFS aren't a serious issue at present.

--
JH
--

-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Mon	Tue	Wed	Thu	Fri	Sat	Sun

				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29

13	April 2013
29	March 2013
17	February 2013
5	January 2013
10	December 2012
4	September 2012
9	August 2012
6	July 2012
15	June 2012
14	May 2012
7	March 2012
70	February 2012
6	January 2012
3	April 2011
6	March 2011
3	January 2011
2	December 2010
8	October 2010
35	September 2010
30	August 2010
5	July 2010
13	June 2010
2	May 2010
37	March 2010
5	February 2010
6	December 2009
9	November 2009
10	October 2009
3	September 2009
10	August 2009
6	July 2009
7	May 2009
4	April 2009
2	February 2009
1	January 2009
3	December 2008
2	November 2008
68	October 2008
9	September 2008
2	August 2008
6	June 2008
2	May 2008
1	March 2008
6	February 2008
4	January 2008
10	December 2007
5	November 2007
5	October 2007
75	September 2007
103	August 2007
69	July 2007
23	June 2007
47	May 2007
17	April 2007
100	March 2007
72	February 2007
11	January 2007
25	December 2006
70	November 2006
85	October 2006
50	September 2006
254	August 2006
93	July 2006
134	June 2006
256	May 2006
129	April 2006
306	March 2006
62	February 2006
126	January 2006
50	December 2005
248	November 2005
73	October 2005
129	September 2005
55	August 2005
48	July 2005
15	June 2005
19	May 2005
13	April 2005
66	March 2005
476	February 2005
61	January 2005
189	December 2004
176	November 2004
88	October 2004
47	September 2004
169	August 2004
99	July 2004
243	June 2004
157	May 2004
137	April 2004
170	March 2004
164	February 2004
157	January 2004
131	December 2003
140	November 2003
195	October 2003
252	September 2003
42	August 2003
26	July 2003
35	June 2003
78	May 2003
21	April 2003
26	March 2003
47	February 2003
100	January 2003
44	December 2002
42	November 2002
147	October 2002
58	September 2002
75	August 2002
7	July 2002
3	February 2000
1	December 1999

MesaLib-6.5 installation problem using jhalfs

Re: MesaLib-6.5 installation problem using jhalfs

Re: What next?

Re: What next?

Re: What next?

Re: What next?