> Ken wrote: >> But, your core already appears to contain things that I have no >> interest in, nor need for. The strength of BLFS has always been >> that you can pick the things you want. The idea of a 'core' implies >> it should always be built.
Qrux wrote: > What's the big deal? Just take out what you don't want. You're the > one inferring "always". I'm saying "this is a useful subset". You read > it as: "You must use these things." No one is saying that. > > I think Bruce made the point succinctly when he said that even with > LFS, you're free to strip out packages when you're done building. You're > free to take things out of "Core", if you're even more minimalist. It's not > like using "Core" is a contract that says you can't use '/bin/rm' or maintain > the system however you want. I'm not sure what the complaint is. I'm just > talking about identifying a subset of the book that could make the claim: > "Hey--if you build these things, you get a hugely more usable system, > even as a bootstrap to build the apps or services you need, because... > umm...you can log into it from another machine, have accurate civilian > time-keeping, be able to basic network-y things, share files, and make > backups." This is not worthless. > > Yes. The idea of a "Core" is that you SHOULD build it. And, along with > that, it will provide features. I think we covered that twice. Just like > with > LFS, you should build a bunch of it, if not all of it. Do you have to keep > it? > Nope. Do you have to keep what's in this "Core"? No. I see this "Core" or "Base" idea as less of something that is absolutely essential. It sounds as though it is intended to contain packages that is common between server and desktop variants of more advanced BLFS. This shouldn't make any of it necessary, aside from any internal dependencies within the book (much like some of the situations in LFS; libpipeline comes to mind). In many distributions, they refer to their basic system toolchains as "base" or "core", and I think this might be some of the disdain towards this whole idea through a bitter taste those words put into mind. A lot of the time, removing something from "base" is a nightmare due to mingled dependencies that one may not be interested in. I also think that people have become attached to the idea of BLFS being entirely an extension to LFS, with the latter being the "base" or "core". Yes, of course people are entitled to change the core as they see fit. But if I go crazy and decide to drop glibc and coreutils for uClibc and busybox, I'm going down a path that lfs-support is going to shake their head at me if I barge in whining that it isn't working. So I can see merit to making a so-called BLFS core to build extended and focused variations of the book upon, complete with a predefined list of packages and an expected chain of build dependencies. But there are also inherit problems with this system including extra maintenance overhead for derivative books in an already maintainer-starved project. All that being said, I think that calling this a BLFS Core is somewhat misleading and unappealing. From the discussion so far I can see that one of the intents is to create a common framework ground on which to derive further implementations. Perhaps we could focus less on it being "Core" and more focus on it as a "Common" framework. People could use the Common book the same way BLFS is currently used today, picking and choosing what they would like (and perhaps with more maintainable expected dependencies, which may also be deviated from by choice of the reader). This would allow us to develop beyond BLFS Common as per usual, and even referencing it when necessary. For example, in one of the extended books you want to install some_package: some_package-0.12.1a_rc16 requires: openssl (refer to BLFS-Common chapter 4) Relatively easy to maintain so long as we don't completely redesign the index every revision. Perhaps not quite as nice as self references within the same book (although being html, cross-referencing via linking is feasible). LFS already refers to BLFS in such a fashion, and I have a suspect that anyone intelligent (or narcissistic) enough to build LFS and BLFS will be able to cross reference a few books in order to achieve a goal. Jonathan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
