For #4 instead of providing built packages perhaps a strong emphasis on
providing good documentation on building certain packages would be
better. So if someone wanted package X they would boot from the
official core LiveCD and build the package themselves using some well
maintained documentation with specific package steps. A community
editable wiki with pages for each package's steps would make keeping the
documentation up to date easier. This would also reduce the burden of
people having to maintain working binary builds as well.
Some general rules for "official" package build community wiki pages:
1. You must assume you are booting from the latest stable core LiveCD
a. So assume available build tools and versions are such as on the CD
2. You must state what version of the software package is being used
3. You must provide links to multiple mirrors of the source for the package
4. Instruct the user step by step from the first boot prompt to the
last install command
Of course the details of where to build the files and how to integrate
them into a custom CD still need filled in. Also would packages built
this way just be doing the same as building LFS? I guess I envision
that any Linux tool or piece of software could get its own detailed step
by step wiki page. Kind of a consolidated Linux software build
instructions repository.
Those are my comments.
--
RB
[EMAIL PROTECTED] wrote:
> Send livecd mailing list submissions to
> livecd@linuxfromscratch.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://linuxfromscratch.org/mailman/listinfo/livecd
> or, via email, send a message with subject or body 'help' to
> [EMAIL PROTECTED]
>
> You can reach the person managing the list at
> [EMAIL PROTECTED]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of livecd digest..."
>
>
> Today's Topics:
>
> 1. [RFC] Proposal of LiveCD project changes (Jeremy Huntwork)
> 2. Re: [RFC] Proposal of LiveCD project changes (Jack Gates)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 19 Oct 2008 16:44:12 -0400
> From: Jeremy Huntwork <[EMAIL PROTECTED]>
> Subject: [RFC] Proposal of LiveCD project changes
> To: Development of LFS LiveCD <livecd@linuxfromscratch.org>
> Cc: LFS Developers Mailinglist <[EMAIL PROTECTED]>, BLFS
> Development List <[EMAIL PROTECTED]>
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hello,
>
> First off, thanks to everyone for the comments given, they were very
> helpful. Based in part on the comments, and upon my own estimation of
> the project, I have a proposal to make wrt the future of the project.
>
> I'll try to keep it as brief as possible, but here are the changes to
> the goals and rules of the project I'm proposing (comments, suggestions,
> corrections and questions most welcome):
>
> 1. Any officially supported and promoted release must not deviate from
> LFS or BLFS in any way.
>
> The purpose of this is to keep the CDs valid as working examples of
> both LFS and BLFS. I do not count as deviations configuration files
> or custom scripts to ease booting or configuring the CD. What I mean
> by deviation is installing packages that do not appear in either
> book, changing the build order for the base system, or using switches
> that either do not appear in the books or are not listed as
> possibilities. A secondary purpose is that by sticking closely to the
> books, it should make development and maintenance of the official CD
> easier.
>
> This limitation will undoubtedly bring up questions regarding extra
> functionality that is currently covered in the latest CDs.
> See item 2 for that.
>
> 2. Packages or build parameters/methods which do not appear in LFS or
> BLFS, but which will undoubtedly increase the CD's value to large groups
> of users can be developed and released in "unofficial" CDs with the hope
> and intention that these changes can be pushed upstream to LFS or BLFS.
>
> A great example here is i18n. A good deal of i18n support is already
> covered in LFS, but there are undoubtedly tweaks that would improve
> the CD's usefulness but do not appear in the books. The "right thing
> to do" in my opinion, is to at the least allow for these sorts of
> modifications in LFS and BLFS. The unofficial CDs provide a sandbox
> for building and testing which can improve the quality and usefulness
> of the books.
>
> 3. The main official CD will be a minimal 'Core' CD. Basically bare LFS
> with just enough added BLFS functionality to connect to the internet (or
> a local network), read an LFS book online, download packages and render
> a book locally.
>
> What is actually included can be discussed and decided upon. I prefer
> once we decide that it be somewhat etched in stone, too. Other
> features can be covered in item 4.
>
> 4. Apart from the core, we can have extra "official" and "unofficial"
> packages which can be added to the core to produce an individual, custom
> CD. The difference between "official" and "unofficial" has to do with
> whether or not the package is included in BLFS and is built by-the-book.
>
> The extent to which we have and provide external packages is based
> the willingness of individuals within the community to maintain them.
>
> 5. The scripts to produce the core official CD shall be rewritten and
> shall look to be done via some PM for ease of maintenance and for ease
> of merging packages into the core.
>
> This may sound like it conflicts with item 1. Technically, it doesn't
> since LFS allows for a PM, but even so, it would have to be a PM
> which doesn't rely on some external libraries not present in LFS.
> Something simple based on tar and shell scripts would be my
> preference, although if we wanted to pursue something like RPM, we
> would have the opportunity to do so in an unofficial CD.
>
> I would hope that by following the above, we would achieve solid, stable
> CDs, a more unified project as a whole, an 'easy to jump in' sort of
> framework which can allow for testing of experimental ideas and pushing
> up the quality of all books.
>
> That's basically it... thoughts?
>
> --
> JH
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 20 Oct 2008 00:09:26 -0400
> From: Jack Gates <[EMAIL PROTECTED]>
> Subject: Re: [RFC] Proposal of LiveCD project changes
> To: livecd@linuxfromscratch.org
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Sunday 19 October 2008 04:44:12 pm Jeremy Huntwork wrote:
>
>> Hello,
>>
>> First off, thanks to everyone for the comments given, they were
>> very helpful. Based in part on the comments, and upon my own
>> estimation of the project, I have a proposal to make wrt the
>> future of the project.
>>
>> I'll try to keep it as brief as possible, but here are the
>> changes to the goals and rules of the project I'm proposing
>> (comments, suggestions, corrections and questions most welcome):
>>
>> 1. Any officially supported and promoted release must not deviate
>> from LFS or BLFS in any way.
>>
>> The purpose of this is to keep the CDs valid as working
>> examples of both LFS and BLFS. I do not count as deviations
>> configuration files or custom scripts to ease booting or
>> configuring the CD. What I mean by deviation is installing
>> packages that do not appear in either book, changing the build
>> order for the base system, or using switches that either do not
>> appear in the books or are not listed as possibilities. A
>> secondary purpose is that by sticking closely to the books, it
>> should make development and maintenance of the official CD
>> easier.
>>
>> This limitation will undoubtedly bring up questions regarding
>> extra functionality that is currently covered in the latest CDs.
>> See item 2 for that.
>>
>> 2. Packages or build parameters/methods which do not appear in
>> LFS or BLFS, but which will undoubtedly increase the CD's value
>> to large groups of users can be developed and released in
>> "unofficial" CDs with the hope and intention that these changes
>> can be pushed upstream to LFS or BLFS.
>>
>> A great example here is i18n. A good deal of i18n support is
>> already covered in LFS, but there are undoubtedly tweaks that
>> would improve the CD's usefulness but do not appear in the books.
>> The "right thing to do" in my opinion, is to at the least allow
>> for these sorts of modifications in LFS and BLFS. The unofficial
>> CDs provide a sandbox for building and testing which can improve
>> the quality and usefulness of the books.
>>
>> 3. The main official CD will be a minimal 'Core' CD. Basically
>> bare LFS with just enough added BLFS functionality to connect to
>> the internet (or a local network), read an LFS book online,
>> download packages and render a book locally.
>>
>> What is actually included can be discussed and decided upon.
>> I prefer once we decide that it be somewhat etched in stone, too.
>> Other features can be covered in item 4.
>>
>> 4. Apart from the core, we can have extra "official" and
>> "unofficial" packages which can be added to the core to produce
>> an individual, custom CD. The difference between "official" and
>> "unofficial" has to do with whether or not the package is
>> included in BLFS and is built by-the-book.
>>
>> The extent to which we have and provide external packages is
>> based the willingness of individuals within the community to
>> maintain them.
>>
>> 5. The scripts to produce the core official CD shall be rewritten
>> and shall look to be done via some PM for ease of maintenance and
>> for ease of merging packages into the core.
>>
>> This may sound like it conflicts with item 1. Technically, it
>> doesn't since LFS allows for a PM, but even so, it would have to
>> be a PM which doesn't rely on some external libraries not present
>> in LFS. Something simple based on tar and shell scripts would be
>> my preference, although if we wanted to pursue something like
>> RPM, we would have the opportunity to do so in an unofficial CD.
>>
>> I would hope that by following the above, we would achieve solid,
>> stable CDs, a more unified project as a whole, an 'easy to jump
>> in' sort of framework which can allow for testing of experimental
>> ideas and pushing up the quality of all books.
>>
>> That's basically it... thoughts?
>>
>> --
>> JH
>>
>
> I am new to LFS. Just got on the list about 3 days ago. I am glad to
> see the LiveCD is going to still be here and I think your
> suggestions sound straight forward.
>
> I have joined several of the lists and have seen a lot of activity.
> Is the New book and LiveCD about to come out?
>
>
--
http://linuxfromscratch.org/mailman/listinfo/livecd
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
