On 07/13/2011 12:53 PM, Rob Landley wrote: > On 07/09/2011 10:16 AM, DJ Lucas wrote: >>>> 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. > Did I link to the time based releases video? > > http://video.google.com/videoplay?docid=-5503858974016723264 > > It is an _awesome_ video, and one of the many things it points out is > that a project that has releases is considered alive, and attracts > interest and users and from the users come developers. A project that > does not have releases has no heartbeat, it seems dead. There may be a > lot of fibrillation, but it doesn't DO anything. > > Interest will naturally fall off in development of a project that hasn't > had releases in a long time. > I'll take a look at it Friday. I've read similar in the past and agree with the points you've made here so far. >>>> 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. > The whole point of LFS is that it doesn't have package management. <Snip> Actually, you've missed the point, likely you didn't take part in the previous discussion on LFS-Dev (~January maybe?). I'll get you a link when I get back in if somebody doesn't beat me to it. LFS's goal is to teach, and that includes managing your system once installed. The proposed 'packaging' doesn't actually produce a package, only installs to DESTDIR to lend a hand in packaging or file system accounting. The real installation is done from DESTDIR to the root so that all post-install steps are included in the book. I did a POC back in 2008 with just shell scripts, and I'm mostly done with an actual book I haven't put up yet, but it's ugly with the lib64 -> lib hack (and a few months out of date now). I'd actually like to propose reversing that symlink at some point as it'll keep from having to pre-create the dirs and symlinks in DESTDIR prior to installation for most packages. >> 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. > I haven't build a system with /opt on it in almost 10 years. > >> Everything goes into /usr or / now >> (and this may even change in the near future on the new standards as >> /usr might go away). > Define "might". Do you have evidence that the Linux Standards Base is > planning to suddenly break compatability with the history of Unix going > back to 1972? Is there any reason for it? Yeah, I do have evidence. We are already breaking the current rules WRT FHS; have been for a bit now for udev...and we're already headed in that general direction. The proposed changes are in FHS, not LSB, but for which LSB will follow. > (Oh, but /opt is better than /usr because nobody uses it therefore it > isn't cluttered! If you "mv /usr /opt" the clutter magically clears > itself up and starts to scale.) Review the current FHS bugs and discussions if you have the available time to search for them. I'll find and post links when I get back if not. >> Taking the gnome example, > I don't care about gnome. I want to ignore Gnome. Making gnome part of > the giant hairball that is BLFS doesn't make a lot of sense to me. > Ouch! That was pretty damn careless! You just dismissed a few thousand hours of work, work done by most of the authors in this very thread. I'll give you the benefit of the doubt and assume that your thoughts didn't translate well into text. Please elaborate.
<Snip> > >>> By considering a branch broken, it would encourage >>> people to submit changes. > On what planet? > > Branches are so convenient because they're easy for everyone else to > ignore. The ones that label themselves as not working up front are > trivial to ignore. > But at least there is some activity. You hinted at that yourself earlier about time based releases and what it means to a user's perception. It is a place to start working toward getting something included in the main book (or books, though I don't particularly see any benefit in that proposal, seems like more work rather than less, more later). >> I'd like to take this a step further. *ANYBODY* who wants a branch, gets >> one. > Um, that's how distributed source control works. It's inherent in it > being distributed source control. You proposed moving to git, so you > get that. It's not a separate point. > Not exactly what I was getting at, I meant on LFS server, but I suppose anybody could use a service like github or what not to make their dirivative works publicly available just to lower the bar for entry. Of course their own servers are an option, just not the low bar of entry I was shooting for to get more community involvement. <Snip> Alright, I need sleep. I'll add any pertinent thoughts I have toward the rest on Friday. -- 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
