On 10/07/11 01:16, DJ Lucas wrote: > On 07/09/2011 01:45 AM, Wayne Blaszczyk wrote: >> On 04/07/11 09:42, Randy McMurchy wrote: >>> Hi all, ...snip... >>> >> 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 I totally agree in dropping /opt, there is just to much overhead in maintaining two sets of instructions.
> 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 I'm not sure what you mean by basic package management. Building binary packages or just keeping a list of what is installed? What I do to keep track of what I've installed is to keep a directory list under /var/db/pkg with various information. > 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. I too use a multilib system due to a work requirement of having to use Citrix ICACLient. What I've done was to build LFS + BLFS as 64 bit, then on another machine built LFS + BLFS as 32 bit, then copy all the necessary 32bit libraries over to the 64 bit machine. All the 32 bit stuff(lib + bin) I've managed to contain under /opt/32bit. I only have 2 sym-links pointing from /lib (ld.so and ld-linux.so). The reason I did it this way is that I didn't want to contaminate my pure 64 bit environment. >> 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, I think this is a very good idea. > 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 ...snip... >> 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. Either way, having links, or just moving the relevant BLFS packages into this new section. I think the LSB section should only cover what is not in LFS. >> 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. Maybe one day. >> Regards >> Wayne. > -- DJ Lucas > > Wayne. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
