On 30-11-2014 08:06, Pierre Labastie wrote: > Le 30/11/2014 11:25, Fernando de Oliveira a écrit : >> 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. >> ... > As noted by Fernando, those two tasks are somewhat incompatible. However > Sisyphus was alone, and fortunately we aren't!
Of course Pierres's sentence is not true applied to mine above. "somewhat icompatible" is an euphemism. > Well, I agree with both Fernando and Ken: it just means that different editors > can do different tasks! That is a *great* discovery!!! Congratulations. >From here, we notice that Pierre is replying to my post, but he is not directing his post to me. What matters is that the "others" be convinced. If Fernando does not agree, his problem. I am not writing here for Pierre, but that same way, to the "others". > > I think one month freeze is not enough to rebuild from scratch all the > packages and test all the sensible paths to one particular package, some of > which may lead to missing deps, while others don't. So it is important that > some editors do regular testing from scratch. Of course, Pierre thinks wrong, here. And nobody in trunk or systemd is building from scratch for all packages, only a few happy ones are the "chosen" ones. I have an example today: Christopher, who told he is building from scratch, wold need to start again, for ekiga, again for thunar and again for xfce4-settings, but just building gnome, is wanting to archive some packages. > > OTOH, it is also important that updates be done regularly, to track > regressions as early as possible. So it is important that some editors > regularly update the packages. It is very nice from Pierre thinking "it is also important that updates be done regularly". Of course, he implies that the really important thing is building from scratch, unfortunately, he cannot do that if someone else does the less noble part of updating the packages. Let us say there are 700 packages, with the average of 4 being released everyday, and let us say it is necessary on average, 2 days to build from scratch to check each: 4 x 2 x 700 = 19600 One machine would need 19600 days to do all needed work. But we have 5 months of update: 5 x 30 = 150 days It would be necessary about 37 machines to do all the work. Let us be more generous: not all of them but only about 400 updates during the cycle. It would be necessary about 21 machines to do all the work. > Also, the use of package managers may allow to suppress all the non-needed > packages to build a specific one, without starting from scratch. It is another > approach, which may somewhat reconcile the two. I completely disagree. As you all see, it seems that Pierre and Fernando have deep disagreements. First one is that Pierre likes to address his important words and thoughts to the nobles, between whom, Fernando is clearly not included, whether he wanted or not. It took a lot of time yesterday trying to sove a new problem in my dev machine, probably with linux pam. -- []s, Fernando -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
