On Sat, Jul 30, 2011 at 08:21:35AM -0700, Qrux wrote: > > In that example, I could see the Desktop "path" including X, Gnome, KDE, > Sound, Video, etc. The production server path wouldn't include compilation > tools, but would include different production-related server packages > (tcpwrappers, NTP, tcpdump, sudo, and your app-server/web-server/RDBMS of > choice). The Dev Server could follow the various language tools, mail > servers, source control, user management (e.g., quotas), etc. > > It doesn't matter if there's package overlap; i.e., if the same package (say, > tcp-wrappers) is in multiple paths; it's simply a matter of keeping each path > "current" and "autocratic", to allow people to follow it easily. Maintainers > of the paths could simply use this list to say: "Hey--I want to integrate > package X into my path. Does anyone have some tips about pitfalls to avoid? > I'm already using configure options L, M, and N, and wondered if there might > be anything to watch out for." I'm, of course, making the assumption > maintainers would have to do that anyway, in the existing BLFS. It seemed > like a safe assumption... > Welcome to the list, please don't top post, and trim what you are replying to. Thanx.
I don't understand how making formal paths through the maze of packages is actually going to help anyone. Perhaps I'm naive, but I already assume that anyone who uses BLFS successfully is going to pick and choose *within* each area. In my opinion, the only way to get more people contributing to the book is to make it easier for them to do this, and I think the idea of a maintainer for a path actually makes it harder than it is now (at the moment, any editor can pick up an unassigned ticket). Do not be fooled, getting the book to render after making an apparently minor change is sometimes a really hard problem, but the bigger problem comes from the book's detail - both the many optional dependencies, and the extra steps to rebuild documentation etc. To take one of your server areas (mail), nobody is likely to have any interest in maintaining the instructions for several different mail servers - you use a maximum of one unless you are trying an alternative. I've got the same problem, but on a much larger scale, with your desktop path. Within X, there are various things I ignore (particularly legacy fonts, but also many of the apps), but I suspect that most people aren't so obsessive about X and just follow the book and build it all, so having a maintainer for it merely formalises who to blame if it is out of date :-( I no longer build any of kde, but even when I used to use parts of kde3, I never built it all. For gnome, there are about 88 packages in the gnome chapter (chapter 34), to say nothing of all the dependencies. I build less than half of those gnome packages. I can probably say the same about each of the areas you have listed, so even if I was tempted to contribute again, adding paths would not make it easier for me. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
