On 7/26/19 10:45 PM, Ken Moffat wrote:
On Fri, Jul 26, 2019 at 09:24:20PM -0500, Bruce Hill wrote:
On Sat, Jul 27, 2019 at 12:38:28AM +0100, Ken Moffat wrote:
On Fri, Jul 26, 2019 at 05:38:07PM -0500, Bruce Hill wrote:
But what would you expect to see in the errata for the development
books ? The current versions are always assumed to be ok, subject to
fixes from pending tickets, but from time to time there are problems.
I would expect no link to errata if there is not going to be errata for the
'development' book.
I'm attempting to find a way which improves the reader's experience
_without_ making (the other) Bruce's job harder when doing releases.
Until now, nobody has been too fussed about this link - so change
needs to be agreed, and it isn't my call.
In this cycle there turned out to be issues with a meson version,
and for a while that was reverted. These sort of things are usually
mentioned on the appropriate -dev lists.
Similarly with vim-8.1 : that is, I think, mentioned in the stable
errata. Similarly for kernel versions with exploitable problems
which have been publically disclosed. So, if you are using an "old"
development snapshot then certainly some of the release errata might
apply.
But for everything else in the current books, unless an open ticket
(check trac for LFS and BLFS) has a priority of high (or greater)
then everything is assumed to be ok.
This seems more appropriate than a link to something non-existent. Maybe one
of the book editors might consider changing it to, "If there is any errata, it
will be published on the lfs-dev mailing list
<http://lists.linuxfromscratch.org/listinfo/lfs-dev/>."
If there is a problem with the development book, it will either be fixed
within a day or two or a ticket created to remind us it fix it before
the next stable release.
The -dev lists are not _for_ errata, but from time to time (e.g.
this week in blfs) people find problems.
I have previously said that people following the dev books should at
least monitor the -dev lists.
You should publish that in the book where it would be read.
The development books are moving targets. It is not, strictly speaking,
published, but are rendered for editors and interested others "as is".
It's my opinion, I know that other editors have said that from time
to time the development books will be broken. I'm in the "once you
know how LFS/BLFS works you should use the dev BLFS book and monitor
dev LFS to pick up security fixes" camp.
Correct. See http://www.linuxfromscratch.org/blfs/read.html
"Current Development
This is the BLFS Book in its current development state. Changes can
happen that break the build of some packages temporarily. Since this
version of the book is in constant change, there is no separate errata."
Normally, the dev book is not
recommended for a first build, but after that - if you wish to use
the dev version, fine - but please be aware of security issues (we
editors might not always be aware of them, particularly in BLFS),
and keep an eye on the dev lists.
I've only done one build, and the dev book was the only one with software
update enough for my host OS. There's not beans worth of difference between
the stable book and the dev book, except (a) the software versions, and (b)
the dev book gets updated at random.
That's difficult to understand. The current stable book is less than 5
months old.
The development book is updated as upstream releases new package
versions. We have no control over when that happens. Some packages are
released several times a month (e.g. kernel), some only every few years
(e.g. grub). Availability as to editors' time also is factored into the
update timing.
Those packages that don't have "beans worth of difference" frequently
have significant security fixes as well as internal improvements, even
if the build instructions do not change.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
