On 29-11-2014 23:49, Ken Moffat wrote: > On Sat, Nov 29, 2014 at 08:23:03PM -0300, Fernando de Oliveira wrote: >> On 29-11-2014 20:02, Christopher Gregory wrote: >> >>> Well its come to this. I will no longer report anything that I find does >>> not compile. What people here are failing to realise is that they are not >>> actually building against a system that is a totaly new installation with >>> everything updated to the latest newest versions. >> >> This is true. When we freeze for the next release is the right time for >> doing that. Doing it in the middle of the terms only delays the updates. >> > > Actually, on _this_ one point I'm with Christopher. I was here > before we became a rolling release, and I prefer to build things in > a fresh system (i.e. lfs-svn) before I commit them. For me, there > are a few exceptions such as firefox and sundry CVE fixes where I > have been willing to commit after merely testing on an existing > released LFS.
It has a freeze period each semester, where everything (almost) is built from scratch. > I think I'll be devoting my BLFS time to doing builds in fresh > systems. Some of this will be in qemu, where for me a lot of things > are pointless (e.g. audio, video, power management, fcron, postfix), > and there are as always a lot of things which I do not build. > > The problem with a rolling release is that breakage is not detected > until somebody tries to build from nothing, just like the problems > which the big distros find when they rebuild everything before a > release. It is a paradox keeping the up to date and building from scratch. Each time you do that, the queue for new package updates (each needing a build from scratch) has increased a lot. And the book will never be up to date. We have a live example now. Build from scratch for each package update is a Sisyphus paradox. -- []s, Fernando -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
