[blfs-support] BLFS-Basic

[Bruce Dubbs]

As most of you know, BLFS is huge. If it is printed on paper, it would
take over 2000 pages. There are over a thousand individual packages in
the book.

In addition, upstream changes are released often. The average is about
3.5 packages every day, seven days a week.

Since LFS/BLFS contributions are done completely by volunteers, the
upstream change rate is overwhelming our ability to keep up to date.
The problem is not LFS. That is doable. The problem is the size and
change rate of BLFS.

To address this, I am proposing to split BLFS into two (or possibly
more) books. My tentative names are BLFS-Basic and BLFS-Advanced.
BLFS-Basic is primarily command line tools and programs plus the basic
Xorg section of BLFS. This would be updated regularly and a 'stable'
version released every six months with the LFS book. The BLFS-Advanced
book will be a 'rolling release'. We did this with BLFS between LFS
versions 6.3 and 7.4 (August 2008 until September 2014).

With a rolling release, there is less consistency and a comprehensive
check against the current stable LFS is not done. Packages would be
frequently out of date.

For BLFS-Basic I am attaching a straw man for the contents. I
anticipate that an experienced LFS builder could complete all the
packages in BLFS-Basic in a day or two.

I am now looking for feedback. Are there other solutions? Is my list
for BLFS-Basic too large? Is there something missing?

-- Bruce

[Ken Moffat]

I am now looking for feedback. Are there other solutions? Is my list for
BLFS-Basic too large? Is there something missing?

After spending 30 minutes attempting to reply, and realising there
are too many potential variations, one question: How separate will
the books be ? One repo, one book labelled as "Part One, Basic" and
"Part Two, Advanced" withing the same document OR One repo, two books
OR Two repos (and two books) ?

I was originally going to ask how you saw links between the two
books working (e.g. actual links or text saying "package FuBar in
the other book"), but this probably also affects jhalfs re
dependencies.

Actually, I would be inclined to move Xorg to Advanced AND drop most
of the legacy parts of it (use fluxbox or one of the other box WMs
for testing, drop twm).

ĸen

[Bruce Dubbs]

Post by Ken Moffat

I am now looking for feedback. Are there other solutions? Is my list for
BLFS-Basic too large? Is there something missing?

After spending 30 minutes attempting to reply, and realising there
are too many potential variations, one question: How separate will
the books be ? One repo, one book labelled as "Part One, Basic" and
"Part Two, Advanced" withing the same document OR One repo, two books
OR Two repos (and two books) ?
I was originally going to ask how you saw links between the two
books working (e.g. actual links or text saying "package FuBar in
the other book"), but this probably also affects jhalfs re
dependencies.
Actually, I would be inclined to move Xorg to Advanced AND drop most
of the legacy parts of it (use fluxbox or one of the other box WMs
for testing, drop twm).

What I had in mind was two separate books, but a Part One/Two in the
same volume is an interesting idea. It would certainly make links
between parts easier and may make changes to jhalfs unnecessary.

I want to keep xorg as a part of basic for two reasons. First, it
doesn't change much, and second I use it as a requirement in my LFS
classes. I do not want to drop the legacy parts because I don't like to
see the warnings in the xorg log. I always do them. Also, since they
are legacy they don't change at all so the maintenance for me amounts to
about 15 minutes every six months.

twm is useful in an educational environment. If twm is present, you do
not need any .xinitrc.

-- Bruce

[Douglas R. Reno]

Post by Bruce Dubbs
As most of you know, BLFS is huge. If it is printed on paper, it would
take over 2000 pages. There are over a thousand individual packages in
the book.
In addition, upstream changes are released often. The average is about
3.5 packages every day, seven days a week.
Since LFS/BLFS contributions are done completely by volunteers, the
upstream change rate is overwhelming our ability to keep up to date.
The problem is not LFS. That is doable. The problem is the size and
change rate of BLFS.
To address this, I am proposing to split BLFS into two (or possibly
more) books. My tentative names are BLFS-Basic and BLFS-Advanced.
BLFS-Basic is primarily command line tools and programs plus the basic
Xorg section of BLFS. This would be updated regularly and a 'stable'
version released every six months with the LFS book. The BLFS-Advanced
book will be a 'rolling release'. We did this with BLFS between LFS
versions 6.3 and 7.4 (August 2008 until September 2014).
With a rolling release, there is less consistency and a comprehensive
check against the current stable LFS is not done. Packages would be
frequently out of date.
For BLFS-Basic I am attaching a straw man for the contents. I
anticipate that an experienced LFS builder could complete all the
packages in BLFS-Basic in a day or two.
I am now looking for feedback. Are there other solutions? Is my list
for BLFS-Basic too large? Is there something missing?
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

After spending hours attempting to come up with something, considering the
amount of variations, I'll share what I have.

I'm of the opinion that we should do one more release of the book as it is
and then discuss things after that. I'm willing to put in as much time as
needs to be put in to keep everything in the book that is currently in
there, for one more release at minimum. Consistency is the thing that is
the most important to me, and one more release would also give people who
use LFS in production the time to adapt their systems for the new changes.
It's way too big of a change to make 1-2 months before release, this should
really be done after.

I've got permission from those around me to contribute as much time as
necessary. I'll test both sysvinit and systemd before release if necessary
as well.

I'm saying this as a person who used to work for a company (not to be named
publicly) that used LFS in production on factory and CNC systems. I'm also
saying this as one who uses it in PROD for weather modeling systems. We
need more than 1-2 months for a huge structure change.

[Bruce Dubbs]

Post by Douglas R. Reno
I'm of the opinion that we should do one more release of the book as it
is and then discuss things after that. I'm  willing to put in as much
time as needs to be put in to keep everything in the book that is
currently in there, for one more release at minimum. Consistency is the
thing that is the most important to me, and one more release would also
give people who use LFS in production the time to adapt their systems
for the new changes. It's way too big of a change to make 1-2 months
before release, this should really be done after.
I've got permission from those around me to contribute as much time as
necessary. I'll test both sysvinit and systemd before release if
necessary as well.
I'm saying this as a person who used to work for a company (not to be
named publicly) that used LFS in production on factory and CNC systems.
I'm also saying this as one who uses it in PROD for weather modeling
systems. We need more than 1-2 months for a huge structure change.

I appreciate that.

I did some playing around with the source yesterday and found that
Docbook supports multiple books in one system. The example from Docbook is:

<set><title>The Perl Series</title>
<setinfo>
<corpauthor>O'Reilly &amp; Associates, Inc.</corpauthor>
</setinfo>

<book><title>Learning Perl</title>
<chapter><title>...</title><para>...</para></chapter>
</book>

<book><title>Programming Perl</title>
<chapter><title>...</title><para>...</para></chapter>
</book>

<book><title>Advanced Perl Programming</title>
<chapter><title>...</title><para>...</para></chapter>
</book>

</set>


I tried that and it works.

On the other hand, we might be able to just reorganize the BLFS book
into two major sections. Basic and Advanced (or some other titles).
The point is that we need to be able to release BLFS with some packages
not being the latest versions and not necessarily tested with the
latest LFS (or just remove those packages).

What we have been doing is a package freeze about two weeks prior to a
scheduled release. For me, that means spending an estimated 100+ hours
in that two weeks building against the new LFS and testing builds and
limited functionality. I just can't do that any more.

In addition, the above assumes that the development version of BLFS is
reasonably current and I have most of the scripts needed for the current
packages in the development version of the book. Right now there are 84
outstanding tickets even though Tim and Thomas and Ken have been doing
updates. Even if we magically got up-to-date today, there would
probably be another 100 or so needed updates before the scheduled
package freeze in mid-August.

What I am looking for is a long term solution so we can continue to put
out a solid product within our constraints.

-- Bruce

[Jalus Bilieyich]

Having multiple parts of the book being split up and teams working on
each part is a good idea in my opinion.

Post by Bruce Dubbs

Post by Douglas R. Reno
I'm of the opinion that we should do one more release of the book as it
is and then discuss things after that. I'm  willing to put in as much
time as needs to be put in to keep everything in the book that is
currently in there, for one more release at minimum. Consistency is the
thing that is the most important to me, and one more release would also
give people who use LFS in production the time to adapt their systems
for the new changes. It's way too big of a change to make 1-2 months
before release, this should really be done after.
I've got permission from those around me to contribute as much time as
necessary. I'll test both sysvinit and systemd before release if
necessary as well.
I'm saying this as a person who used to work for a company (not to be
named publicly) that used LFS in production on factory and CNC systems.
I'm also saying this as one who uses it in PROD for weather modeling
systems. We need more than 1-2 months for a huge structure change.

I appreciate that.
I did some playing around with the source yesterday and found that
<set><title>The Perl Series</title>
<setinfo>
<corpauthor>O'Reilly &amp; Associates, Inc.</corpauthor>
</setinfo>
<book><title>Learning Perl</title>
<chapter><title>...</title><para>...</para></chapter>
</book>
<book><title>Programming Perl</title>
<chapter><title>...</title><para>...</para></chapter>
</book>
<book><title>Advanced Perl Programming</title>
<chapter><title>...</title><para>...</para></chapter>
</book>
</set>
I tried that and it works.
On the other hand, we might be able to just reorganize the BLFS book
into two major sections. Basic and Advanced (or some other titles).
The point is that we need to be able to release BLFS with some packages
not being the latest versions and not necessarily tested with the
latest LFS (or just remove those packages).
What we have been doing is a package freeze about two weeks prior to a
scheduled release. For me, that means spending an estimated 100+ hours
in that two weeks building against the new LFS and testing builds and
limited functionality. I just can't do that any more.
In addition, the above assumes that the development version of BLFS is
reasonably current and I have most of the scripts needed for the current
packages in the development version of the book. Right now there are 84
outstanding tickets even though Tim and Thomas and Ken have been doing
updates. Even if we magically got up-to-date today, there would
probably be another 100 or so needed updates before the scheduled
package freeze in mid-August.
What I am looking for is a long term solution so we can continue to put
out a solid product within our constraints.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[Ken Moffat]

Post by Jalus Bilieyich
Having multiple parts of the book being split up and teams working on
each part is a good idea in my opinion.

Except at the moment we have one small team and in general people
pick things they think they can handle. In my case, a lot of the
things I care about are spread throughout the 'Basic' and 'Advanced'
parts, and I'm sure the other editors will say the same. So I'm not
convinced that separate teams is going to work.

For the moment I'm mostly stepping aside, as previously noted.

I hope to keep an eye on firefox (past experience suggests that
trying to pick up the new version only when it is released is too
painful), and almost every release has CVE fiexes, even 61.0 did
(although those were not initially in the Release Notes).

Eventually I hope to be able to devote a bit more time to this, but
for the next few months that is now less likely.

But the big problems as I see them are:

· lack of people building the development book and finding issues

· lack of people willing and able to edit

And of those, the second is the greater problem.

So, since we are now hopefully looking at longer-term changes,
anybody else got other suggestions for changed format/process ?

Please ?

ĸen

[Douglas R. Reno]

Post by Ken Moffat

Post by Jalus Bilieyich
Having multiple parts of the book being split up and teams working on
each part is a good idea in my opinion.

Except at the moment we have one small team and in general people
pick things they think they can handle. In my case, a lot of the
things I care about are spread throughout the 'Basic' and 'Advanced'
parts, and I'm sure the other editors will say the same. So I'm not
convinced that separate teams is going to work.
For the moment I'm mostly stepping aside, as previously noted.
I hope to keep an eye on firefox (past experience suggests that
trying to pick up the new version only when it is released is too
painful), and almost every release has CVE fiexes, even 61.0 did
(although those were not initially in the Release Notes).
Eventually I hope to be able to devote a bit more time to this, but
for the next few months that is now less likely.
· lack of people building the development book and finding issues
· lack of people willing and able to edit
And of those, the second is the greater problem.
So, since we are now hopefully looking at longer-term changes,
anybody else got other suggestions for changed format/process ?
Please ?
Äžen
--
Keyboard not found, Press F1 to continue
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Would this be the time to suggest a change in policy on tickets? I'd like
to see tickets have the changelog for the package and security updates
marked as such. It would make people's lives a lot easier.

[Bruce Dubbs]

Post by Douglas R. Reno
Would this be the time to suggest a change in policy on tickets? I'd
like to see tickets have the changelog for the package and security
updates marked as such. It would make people's lives a lot easier.

I'm not sure what you mean Douglas. Most of the time we add the release
notes or change log to the tickets. However some packages do not say
what changed (e.g. libinput).

-- Bruce

[Douglas R. Reno]

Post by Bruce Dubbs

Post by Douglas R. Reno
Would this be the time to suggest a change in policy on tickets? I'd
like to see tickets have the changelog for the package and security
updates marked as such. It would make people's lives a lot easier.

I'm not sure what you mean Douglas. Most of the time we add the release
notes or change log to the tickets. However some packages do not say
what changed (e.g. libinput).
--

I have seen it with the most recent package updates. Most of the time,
depending on the editor, the changes are listed. The samba, php, etc.
updates that were recently completed were not listed with changes.

Another thing - would it be worth adding a page to tell potential
contributors how to contact you (Bruce) regarding contributions?

I dont know if anyone here has heard of Discord, but there is a LFS discord
ran unofficially there with lots of people who use it daily and could
possibly contribute. I lurk there occasionally. It can be used over both a
web browser or a desktop application.

[Ken Moffat]

Post by Bruce Dubbs

Post by Douglas R. Reno
Would this be the time to suggest a change in policy on tickets? I'd
like to see tickets have the changelog for the package and security
updates marked as such. It would make people's lives a lot easier.

I'm not sure what you mean Douglas. Most of the time we add the release
notes or change log to the tickets. However some packages do not say what
changed (e.g. libinput).
-- Bruce

Addressing only the security fixes -

I usually skim through the security updates at lwn.net, looking to
see if anything I use ought to be updated. Many of those turn out
to be for old versions in debian (some versions - others can be
bleeding edge), ubuntu, SuSe, Centos, and can be ignored. But from
time to time I see things like firefox-61 : I kept the ticket open
until the release notes were out, and at that time no CVE fixes were
mentioned. Later Arch flagged it as a security update and the CVEs
had been added to mozilla's Release Note.

For examples like that, the options seem to be:

1. do nothing, svn has already been updated.

2. belatedly note the CVE fixes somewhere in the already-closed
ticket.

3. set up a separate page on the website (it could be ongoing, i.e.
keep details for a longer period than just the next release), also
covering LFS, with details such as:

firefox-61.0 : various CVE fixes

FuBar-88.1 : various CVE fixes

firefox-60.0.2 : various CVE fixes

...

LFS-8.2 released

(no point at the moment in looking back beyond that)

For many packages, it is not just one CVE fix (or alternatively,
e.g. openssl, curl, they have their own notifications which might be
public before the CVE details), so maybe just describe the whole
page as 'security fixes'.

But there is also the question of whether a particular vulnerability
is likely to affect our users.

No doubt some people will say that in a rolling release we should
just rebuild everything on our own system(s) in case it fixes
vulnerabilities. But that seems like a waste of electricity, and
therefore a contribution to global warming.

ĸen

[Hazel Russman]

On Tue, 10 Jul 2018 23:44:24 +0100

Post by Ken Moffat

Post by Jalus Bilieyich
Having multiple parts of the book being split up and teams working
on each part is a good idea in my opinion.

Except at the moment we have one small team and in general people
pick things they think they can handle. In my case, a lot of the
things I care about are spread throughout the 'Basic' and 'Advanced'
parts, and I'm sure the other editors will say the same. So I'm not
convinced that separate teams is going to work.
For the moment I'm mostly stepping aside, as previously noted.
I hope to keep an eye on firefox (past experience suggests that
trying to pick up the new version only when it is released is too
painful), and almost every release has CVE fiexes, even 61.0 did
(although those were not initially in the Release Notes).
Eventually I hope to be able to devote a bit more time to this, but
for the next few months that is now less likely.
· lack of people building the development book and finding issues
· lack of people willing and able to edit
And of those, the second is the greater problem.
So, since we are now hopefully looking at longer-term changes,
anybody else got other suggestions for changed format/process ?
Please ?
ĸen

I have done editing before; I was a proofreader for the Open Document
team for years. But I have *zero* experience of svn and I don't
understand docbook/xml at all. Still, if there are any simple jobs that
I could do to help, I would be willing.

I've been using LFS for some years now and it's probably my favourite
distro. Maybe it's time to give something back.
--
If any members of GCHQ are reading this, shame on you! I fought for
your right to belong to a trade union and now you are taking away my
right to privacy?

Hazel Russman

[Ken Moffat]

Post by Hazel Russman
I have done editing before; I was a proofreader for the Open Document
team for years. But I have *zero* experience of svn and I don't
understand docbook/xml at all. Still, if there are any simple jobs that
I could do to help, I would be willing.
I've been using LFS for some years now and it's probably my favourite
distro. Maybe it's time to give something back.

I was going to point you, and anybody else who might be interested,
to the BLFS editor's guide - but the online version is slightly out
of date (I added a bit to chapter 6 a few months ago and I see that
is not in the online version).

Nevertheless, it gives the basics, including svn access, and is at
http://www.linuxfromscratch.org/blfs/edguide/

For rendering the beastie, I build all of chapters 50 and 51
_except_ itstool.

For editing (mainly used when adding new pages, but a useful
reference) there is a template/ directory in the book's XML source.

Bruce: the online version is at
/srv/www/www.linuxfromscratch.org/blfs/edguide
: which repo has that, please ?

ĸen

[Bruce Dubbs]

Post by Ken Moffat

Post by Hazel Russman
I have done editing before; I was a proofreader for the Open Document
team for years. But I have *zero* experience of svn and I don't
understand docbook/xml at all. Still, if there are any simple jobs that
I could do to help, I would be willing.
I've been using LFS for some years now and it's probably my favourite
distro. Maybe it's time to give something back.

I was going to point you, and anybody else who might be interested,
to the BLFS editor's guide - but the online version is slightly out
of date (I added a bit to chapter 6 a few months ago and I see that
is not in the online version).

I'll try to get that updated later today.

Post by Ken Moffat
Nevertheless, it gives the basics, including svn access, and is at
http://www.linuxfromscratch.org/blfs/edguide/
For rendering the beastie, I build all of chapters 50 and 51
_except_ itstool.

Let me describe here a summary of using svn and a very brief intro to
rendering the book's dockbook sources.

Overall svn consists of the commands:

svn <argument> [operand]

where the most useful arguments are checkout, commit, add, mv, and diff.

The basic checkout is

svn co svn://svn.linuxfromscratch.org/BLFS/trunk/BOOK/ BLFS

For editors with commit privileges, an account is needed on the server
(ask me if you want that). IN that case the checkout argument is
svn+ssh://....

The above will create a directory BLFS and the source is there. To
build the book look in the INSTALL file in the source. It documents the
packages needed:

libxml2
libxslt
DocBook XSL Stylesheets-1.68.1
DocBook XML DTD-4.5
tidy

To create a local copy of the html, just run 'make'. For the systemd
version of the book run 'make REV=systemd'. The output, by default,
will be $(HOME)/public_html/blfs-book or $(HOME)/public_html/blfs-systemd.
-----

Editing Docbook sources is really pretty easy. Just use a text editor
(please, do not embed tab characters. For vim, use ':set et').

If you've ever edited html, Docbook will be very easy. Just look at the
current pages for examples. If you make changes and run into problems,
just ask. That's the way to learn.

Post by Ken Moffat
For editing (mainly used when adding new pages, but a useful
reference) there is a template/ directory in the book's XML source.
Bruce: the online version is at
/srv/www/www.linuxfromscratch.org/blfs/edguide
: which repo has that, please ?

I've updated the website now: http://www.linuxfromscratch.org/blfs/edguide/

-- Bruce

[Thomas Trepl]

Post by Bruce Dubbs
As most of you know, BLFS is huge. If it is printed on paper, it would
take over 2000 pages. There are over a thousand individual packages in
the book.

Wow, never seen that in this way...

Post by Bruce Dubbs
In addition, upstream changes are released often. The average is about
3.5 packages every day, seven days a week.
Since LFS/BLFS contributions are done completely by volunteers, the
upstream change rate is overwhelming our ability to keep up to date.
The problem is not LFS. That is doable. The problem is the size and
change rate of BLFS.

Yes, its a huge amount of work which is to be done to keep all those
packages up-to-date. Moreover, not only keeping them up-to-date in
terms of using the most current version, it's the review of the
instructions all the time, checking for new config options, the check
of interoperability with other packets and so on - not just dropping in
a new version number and updating the md5 chksum.

Post by Bruce Dubbs
To address this, I am proposing to split BLFS into two (or possibly
more) books.

Yes, divide into two (or more) "physically" different books. They could
be maintained and tagged independently. The maintenance than could be
organized in svn-branches on those books.

---> [BLFS-8.2] ---> stable Basic BLFS-8.2 -----------> [BLFS-8.3] --->
| ^ ^
| | |
| Security patches / Bugfixes | for rls merge
| ^ | dev-8.3 to HEAD
| | |
+-----> Devel for next rls (dev-8.3) -------+

The devel-branch could be merged more than just one time if required to
the HEAD, just creating a BLFS-Basic-8.2.x release. Just a thought...

Post by Bruce Dubbs
My tentative names are BLFS-Basic and BLFS-Advanced.
BLFS-Basic is primarily command line tools and programs plus the basic
Xorg section of BLFS. This would be updated regularly and a
'stable'
version released every six months with the LFS book. The BLFS-
Advanced
book will be a 'rolling release'. We did this with BLFS between LFS
versions 6.3 and 7.4 (August 2008 until September 2014).

A pretty cool idea. One question i have is: Would BLFS-Basic have
impact on the release of a new LFS-version. When releasing a new LFS,
the BLFS-Basic should be available in time also.

Post by Bruce Dubbs
With a rolling release, there is less consistency and a
comprehensive
check against the current stable LFS is not done. Packages would be
frequently out of date.

... which is IMHO no problem at all if accepted that this may not
address security issues in a proper way and such. xLFS is primarily for
teaching how stuff works by showing instructions with which something
can be built without using esotheric stuff like packetmanagers (while
everyone of us has built his/her own one, isn't it?). xLFS never had
the aim to be a full-featured distro.
I see issues with linking from one book to the other, but with clever
xml-entities we should come over it, right?
The impact on jhALFS is unknown to me as i use my own pkgmngr - so no
idea about this.

Post by Bruce Dubbs
For BLFS-Basic I am attaching a straw man for the contents. I
anticipate that an experienced LFS builder could complete all the
packages in BLFS-Basic in a day or two.
I am now looking for feedback. Are there other solutions? Is my list
for BLFS-Basic too large? Is there something missing?

Maybe check the list for packages like "at" or "(f)cron" which are
called to be a requirement for LSB compliance.
Add the minimum toolset to be able to rebuild the LFS/BLFS-Basic book.
To much WMs. Just FluxBox (or one of the others) would be enough.


All in all, it would be an interesting project in the xLFS hemisphere!

--
Thomas

[Paul Rogers]

Post by Douglas R. Reno
currently in there, for one more release at minimum. Consistency is the
thing that is the most important to me, and one more release would also
give people who use LFS in production the time to adapt their systems
for the new changes.

I do understand the problem, but I forsee one pretty big hassle forthcoming. The one thing to say about the existing book is: one is quite certain all the packages are consistent with each other. Split in two, or even more (networking & GUI stuff suggests themselves), the idea presents itself: different release readiness for different sections, and separate development tracks probably lead to package version inconsistencies. If one decides to enforce keeping them in-step, what really have you gained?

This is somewhat the situation I found when I came aboard with 4.1: BLFS was still 1.0! It jumped from 1.0 to 5.x.

Perversely, perhaps one should explode the book altogether! Have each package separate, on its own development track, then have wget and make files. Shift entirely to the sort of thing in the SVN versions. Granted, everybody would likely have a unique system build, making support very troublesone.

[Cheyenne McNutt]

Chey here, I'm willing to help Doug as he needs it until we get this next
release out. Him and I rebuilt my machine today that I was going to
originally use before we left, so I'm going to be building that machine out
over the next several days. I'm willing to do whatever is necessary to help
get one more release out with things as they are right now.

Post by Paul Rogers

Post by Douglas R. Reno
currently in there, for one more release at minimum. Consistency is

the

Post by Douglas R. Reno
thing that is the most important to me, and one more release would

also

Post by Douglas R. Reno
give people who use LFS in production the time to adapt their systems
for the new changes.

I do understand the problem, but I forsee one pretty big hassle
forthcoming. The one thing to say about the existing book is: one is quite
certain all the packages are consistent with each other. Split in two, or
even more (networking & GUI stuff suggests themselves), the idea presents
itself: different release readiness for different sections, and separate
development tracks probably lead to package version inconsistencies. If
one decides to enforce keeping them in-step, what really have you gained?
This is somewhat the situation I found when I came aboard with 4.1: BLFS
was still 1.0! It jumped from 1.0 to 5.x.
Perversely, perhaps one should explode the book altogether! Have each
package separate, on its own development track, then have wget and make
files. Shift entirely to the sort of thing in the SVN versions. Granted,
everybody would likely have a unique system build, making support very
troublesone.
--
Paul Rogers
Rogers' Second Law: "Everything you do communicates."
(I do not personally endorse any additions after this line. TANSTAAFL :-)
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[Riccardo G Corsi]

I like BLFS-Core. The other areas you suggest are really separate
chapters in BLFS as it is now. The problem with the profiles you
suggest is the dependencies that many different areas rely upon.
-- Bruce

I understand the problems.
At the moment I'm experimenting packaging with "Slackware standard" of
my BLFS compilations, for future rolling releases.
I will try later to download the book & try if I can do some small tasks
in help editing.
Riccardo

[thomas]

Post by Bruce Dubbs
...
In addition, upstream changes are released often. The average is
about 3.5 packages every day, seven days a week.
...
To address this, I am proposing to split BLFS into two (or possibly
more) books. My tentative names are BLFS-Basic and BLFS-Advanced.
BLFS-Basic is primarily command line tools and programs plus the basic
Xorg section of BLFS. This would be updated regularly and a 'stable'
version released every six months with the LFS book.

Just a thought:

What if we would use only *stable* versions of packages in the
BLFS-*Stable* book?

Ok, the book would than be not so bleeding-edge (but rock-solid i
assume). This would reduce the amount of updates we would have to make
in order to keep it on the very recent status. For example, bind
(DNS-server) had two tickets to upgrade to 9.13.1 and a few days later
to 9.13.2. Two tickets which may simply drop out if stable-book stick on
stable version 9.12.2.

What do you think?

--
Thomas

[Bruce Dubbs]

Post by thomas

...
In addition, upstream changes are released often.  The average is
about 3.5 packages every day, seven days a week.
...
To address this, I am proposing to split BLFS into two (or possibly
more) books.  My tentative names are BLFS-Basic and BLFS-Advanced.
BLFS-Basic is primarily command line tools and programs plus the basic
Xorg section of BLFS.  This would be updated regularly and a 'stable'
version released every six months with the LFS book.

What if we would use only *stable* versions of packages in the
BLFS-*Stable* book?

All of BLFS tries to use only stable releases now. There are some
exceptions when a package uses a development library release, but it's rare.

Post by thomas
Ok, the book would than be not so bleeding-edge (but rock-solid i
assume). This would reduce the amount of updates we would have to make
in order to keep it on the very recent status.  For example, bind
(DNS-server) had two tickets to upgrade to 9.13.1 and a few days later
to 9.13.2. Two tickets which may simply drop out if stable-book stick on
stable version 9.12.2.

Why do you think bind-9.13 is a development release? If it is and I've
missed it, I need to update the currency scripts to reflect that.

The problem here is that different packages use different methods to
designate development releases. Some use even/odd minor versions. Some
use -RCx or -dev, some use minor or point version numbers >= 80 or 90.
This list is not exhaustive.

Add to that that some developers do not bother to do development
releases. Sometimes we see three 'stable' releases in a week.

-- Bruce

[Thomas Trepl]

Post by Bruce Dubbs

Post by thomas

Post by Bruce Dubbs
...
In addition, upstream changes are released often. The average is
about 3.5 packages every day, seven days a week.
...
To address this, I am proposing to split BLFS into two (or
possibly
more) books. My tentative names are BLFS-Basic and BLFS-
Advanced.
BLFS-Basic is primarily command line tools and programs plus the basic
Xorg section of BLFS. This would be updated regularly and a 'stable'
version released every six months with the LFS book.

What if we would use only *stable* versions of packages in the
BLFS-*Stable* book?

All of BLFS tries to use only stable releases now. There are some
exceptions when a package uses a development library release, but it's rare.

Post by thomas
Ok, the book would than be not so bleeding-edge (but rock-solid i
assume). This would reduce the amount of updates we would have to make
in order to keep it on the very recent status. For example, bind
(DNS-server) had two tickets to upgrade to 9.13.1 and a few days later
to 9.13.2. Two tickets which may simply drop out if stable-book stick on
stable version 9.12.2.

Why do you think bind-9.13 is a development release? If it is and I've
missed it, I need to update the currency scripts to reflect that.

Go to https://www.isc.org/downloads/ and open the dropdown-box for
"bind".
The list will state 9.13.2 as unstable/development in red letters,
9.12.2 as current-stable in green.

Post by Bruce Dubbs
The problem here is that different packages use different methods to
designate development releases. Some use even/odd minor
versions. Some
use -RCx or -dev, some use minor or point version numbers >= 80 or 90.
This list is not exhaustive.
Add to that that some developers do not bother to do development
releases. Sometimes we see three 'stable' releases in a week.

Yeah, all that happens, too :-)

--
Thomas