On 07/09/2011 01:45 AM, Wayne Blaszczyk wrote: > On 04/07/11 09:42, Randy McMurchy wrote: >> Hi all, >> >> It has been some time, though I have read every message to all the lists >> for the last several months. I want to keep this short, but start a >> conversation that could lead us to the direction (if there is any) we need >> to go. >> >> What do we do with the behemoth that is BLFS? >> >> Is it maintainable? Sure it is...but lets take a better look at Wayne's suggestions below... >> There are just so many dependencies in the grand scheme of things now, that >> it is almost impossible to update one package without it affecting (or >> requiring) another package. It is dependency hell, now. Or so it seems. >> >> Suggestions are welcome. Volunteers are required. LFS is skating by with >> only two people contributing. BLFS needs much more support than that. We need more people and I think we'll have to relax the editor requirement a bit. >> Discussion? Or is the thought of a maintainable BLFS unachievable? >> >> For what it is worth I'm building a GNOME 3.x system now and have many >> updates I could do, but is it worth it? >> > Is it maintainable? > In theory it's maintainable, but going on current trend, it's not. At > the rate we going, a final release will never happen. > One problem that I can see apart from not enough volunteers is > collaboration. One example that stood out was when Gnome was being > updated. I was doing my thing, DJ was doing his Gnome build, and so on. > Yes there was some emails thrown around with suggestions which did help, > but I feel that time could have been better spent if we both updated the > Gnome section at the same time. Actually, there was a very good reason for our divergence, and it's one I've been complaining about for a long time. This problem falls back to LFS. There is no package management so we, as editors, tend to go about managing things differently. One of those management issues is the /usr vs /opt debate. I want to drop the /opt anything in BLFS proper and let package management do it's thing. Everything goes into /usr or / now (and this may even change in the near future on the new standards as /usr might go away). Taking the gnome example, getting gnome to play nicely in both /usr and /opt/gnome took months (and still doesn't work exactly correctly). We need some form of basic package management in LFS and we need to continue that in BLFS. Even the most basic DESTDIR builds in LFS with tar.gz 'packages' would be sufficient (and as stated before, this style lends itself well to many of the others, including RPM which seems to be rather popular among current and past editors). As it is now, I don't even use LFS proper because of lack of multi-lib support which I *need*. I use a hacked up patchwork of CLFS and LFS (I like LFS's package selection better) but maintaining that alone takes up a lot of my time. > Now I know that this would be difficult > to do, but that's because I feel we are using the wrong model for > development. We don't exploit the branching model. If we were to move to > Git where branching is cheap and merging is easier, things could get > done a lot quicker. As an example, if we had a development branch (The > trunk branch would be for final releases only.), and someone decided to > update Xorg 7.7 or Gnome 3.0.1, then a feature branch would be created > off the development branch. This new branch would be considered broken > until it was completed. Once completed, it would be merged back to the > development branch. By considering a branch broken, it would encourage > people to submit changes. Our current model discourages this because > people are constantly worried that their submission (or partial > submission) might break something else, or they'll tread on someone > else’s hand. Continuing with the example, if Gnome 3.0.1 was being > worked on, and in the meantime 3.0.2 came out, someone could create a > new Gnome 3.0.2 branch off the development branch and merge in all the > 3.0.1 changes. This way whoever wanted to continue with 3.0.1 could do > so, and others could continue with 3.0.2. If 3.0.1 was finished first, > then that could be pulled back to the development branch. If 3.0.2 was > completed first then that could be pulled back, and 3.0.1 would be > deemed as a dead branch, never to be merged back to development. The > above example implies that all branches are public and that all branches > are automatically built and available to the public online so they can > choose which version of the book to work off. I'd like to take this a step further. *ANYBODY* who wants a branch, gets one. Current Main and any stable branches are off limits to new 'developers,' and merging is done by the 'editors' group. As I see it, this addition does two things for the project. First we get new talent and manpower from anybody who wants to contribute, effectively lowering the bar for entry, plus it is a way to evaluate the skills of future core editors. We need more people involved, and this just seems like a step in the right direction to me. > We could even take another > step back and have multiple versions of the development branch, > dev-LFS-6.7, dev-LFS-6.8, dev-LFS-svn, etc... This would result in > possibly having multiple branches of the same thing, e.g. dev-LFS-6.7 → > Gnome 3.0.2 and dev-LFS-6.8 → Gnome 3.0.2, but as I said, in GIT > branches are cheap... If this path was taken then we would need to get > rid of general.ent and keep the versions within the individual pages > (keep it atomic) otherwise this part would be a merging nightmare. > > In relation to some other suggestions. Going to a wiki style is not > going to solve our current problems. Maintaining a book and maintaining > a wiki should take about the same amount of effort. The reason why CBLFS > seems to be easier is that it has less information to worry about, e.g. > build times, bin and lib list, etc. Another way to make merging easier > is to use something other than docbook. If we were to use a more custom > defined xml schema, specific to just building packages, and then > converting this to docbook, we would get a more consistent look and not > worry about formatting styles. > > Splitting the BOOK up into smaller books, e.g. X11, Gnome, Kde, might > sound good, but I feel that this would have it's own problems. As an > example, having a separate Gnome book, would GTK go into this book? > Glib, libsoup, etc... If not then we will probably have break problems > due to wrong versions. If yes, then what about other application the > depend on these packages, do we reference them across books or do we > duplicate the package? > > Speaking of sections, I think we should have new sections for LSB, i.e. > all packages that make up LSB build, further divided up into it's > modules, Core, Desktop, etc. Agreed on all points above. What did you have in mind for LSB? A page of links to other sections in the books? As it is now, LFS has about 75%, maybe 80% coverage of Core. > On a side note, over the last few months I been working on my own > project which is an automated build process that takes in Jhbuild module > files both from Gnome and Xorg, the BLFS book and my own custom defined > files that describe packages that are not to be found elsewhere and > merging them into a single custom defined xml file. Then using this > file, I can kick of an auto build. Sounds cool, but would be even cooler if it were a ?ALFS project. > Regards > Wayne. -- DJ Lucas
-- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
