On Fri, Jul 5, 2013 at 6:01 PM, Fernando de Oliveira <[email protected]> wrote: > Em 05-07-2013 20:06, Bruce Dubbs escreveu: >> akhiezer wrote: >> >>> Just for the avoidance of doubt: I think (fwiw) that a rolling-'release' is >>> overall not a good(-enough) idea per se, whether based on upstream 'stable' >>> or >>> upstream 'unstable'; >> >> Perhaps, but I think it is as good as possible with the available manpower. > > In other words, I believe you agree that it would be good to have many > more developers, enough to produce point releases. > >> >>> And _everyone_ essentially has to do this, entailing a fairly massive and >>> unnecessary reproduction of work across users of BLFS. Sure, there can be >>> side-benefits such as folks getting more familiar with the 'realities' of >>> the >>> lower-levels and inner-workings of the dev/commit process &c. But is that >>> level >>> of involvement a _requirement_ for using BLFS: or should the person be able >>> to >>> go and get a proper formal release and be able to work principally from that >>> and not have to follow trac/dev-lists/&c as much as with the >>> rolling-'release' >>> scenario. >>> >>> >>> IOW, by shifting to rolling-'release', I'd argue that BLFS has overall >>> increased the barriers to entry, for folks; and _as such_ is overall now >>> less >>> educational. >> >> It's interesting that I recently did a BLFS build for myself without >> considering if the packages were the latest or not -- just what was in >> the book. It helped that I already had scripts for about every package, >> but a lot had to be updated in generally small ways to get to the BLFS >> package version. I generally had to comment out the tests because I >> didn't want to take the time and I figured the editor that last updated >> the book had done that for me. >> >> The packages selected were those that I wanted to use. I didn't build >> everything, but I did build xfce and kde. The order of packages was as >> the dependencies dictated. >> >> I was actually suprised in how easily things went together. There were >> very few problems. Getting from LFS -> Xorg -> WM is a pretty long >> process, but BLFS seemed to work as intended. >> >> Right now I'm up to a little over 300 BLFS packages. >> >> -- Bruce >> > > I added a comment above, but I replied this mostly to agree with Bruce, > word by word. My newest build was (differently from previous) using the > book as it is, versions as they were in the book (exception: openjdk and > icedtea-web, where I used more recent ones). Very few and small > problems. Things are very good, in the book. > > LFS -> Xorg -> WM too, but I use LXDE (with Openbox from the book). > > -- > []s, > Fernando > --
For myself I have been sticking to LFS and BLFS development versions, occassionally encountering various broken setups [a lot more rare then previously] (Usually due to my own custom changes, but sometimes a blfs package that was not up to date). My own system is basically a rolling release, but I have my own build scripts I maintain myself, But all in all BLFS seems to be in quite good shape these days. Before we had rolling releases, BLFS began to lag a bit behind LFS (where there was no BLFS release for every LFS release). Users of LFS would need to either use old BLFS instructions, or go to the development version. The reason was that we needed to freeze before a release, and test all of the packages to ensure they worked as expected. This took time we did not have the manpower for. In comparison, we are no longer holding back on package updates in BLFS. Possibly not as much testing on every single possibility (I have not seen any major problems). This is a compromise to be sure, and I imagine if we reacquire the manpower then actual releases could be reconsidered. There are some little things I wish could change (And wanting to add that I am very happy to see all the recent changes to BLFS), but I might as well just throw it out there. - 1 commit per package update: I follow blfs-book to update my scripts, and it can get a bit tedius when 5-10 packages are updated in a single commit. Especially if I want to update some packages now, and others later. - (alternative) bulk package update commits do not have instruction changes: If bulk changes did not change the build instructions, it would be much easier to follow. -- Nathan Coulson (conathan) ------ Location: British Columbia, Canada Timezone: PST (-8) Webpage: http://www.nathancoulson.com -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
