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/>." > 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. > 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. > > 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. > In practice, things get changed when required - that includes the instructions and the package order. All package releases can be described as happening at random times (with the possible exception of the kernel, which usually goes through around 6 -rc versions, but even there critical stable fixes will appear at random). The book warns, for some packages, that newer host versions have not been tested. That doesn't mean they won't work. Do you have any specific LFS packages where you required a newer version to build on your host distro ? ĸen -- One pill makes you larger, And one pill makes you small. And the ones that mother gives you, Don't do anything at all. Go ask Alice, When she's ten feet tall. -- Jefferson Airplane, White Rabbit -- 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
