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? > > 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. > > 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. 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. 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. 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. Regards Wayne. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
