Am Montag, den 09.07.2018, 15:08 -0500 schrieb 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...
> 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.
> 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...
> 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.
> 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.
> 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
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
