FWIW... DJ Lucas wrote: > Fortunately, that is not a deal breaker for me if the > readers get the same treatment (which seems to be the case), but this > does hard code optional dependencies for the pre-packaged installations. > This is both good and bad. From a development standpoint, it won't take > me a week to build a fairly standard system to test a simple package > upgrade, but that still means manual (or maybe only partially automated) > builds for omitting optional deps in the build process up to the point > that I need.
This exact reason, for the record, is why I really dislike binary distros. I *never* choose the same set of dependencies that are optional in the source, as the distro does. And because when they ran ./configure, they added a --with-foo flag, the package compiled with -lfoo, meaning the binary version of the package now has a hardcoded requirement for libfoo.so.N or whatever it is. For example, python and bluez. I don't want an entire bluetooth stack. But some distros' python packages require that stack in order to run. For another example, gtk+ (both 2 and 3), or chrome, or firefox, and CUPS: I don't want an entire printserver stack (since I only have a single printer, and only use it from one machine). Or xine-lib and ... well, any half of its dependencies, depending on what you're going to use it to play. :-) Now I should say that I don't think this necessarily applies to BLFS, except inasmuch as testing with or without some of the optional dependencies might require changes to the package in question. (If the CUPS-less version of FF needs some other configuration different from the FF-with-CUPS binary, for instance. I don't think that's the case today at least.) OTOH when building a system I can probably figure that out, too. > My hope is that build order is still a manual process where the user > determines build order herself. Dependency checking is done only at > build time and that optional deps remain optional. If there will be > automation, how do we determine what optional deps to pull in? Perhaps it makes more sense to just keep ALFS the way it is, and not build packages? I *know* that I won't be building any package-ish thing for my systems at all; I'm still using an oldish version of MSB's package-user setup, so none of this applies. In other words, I think it'd help to only use packages to simplify (mostly BLFS) testing, but make them semi-public for people who really want them. Don't use them at all in the actual build instructions (what would be the point? :-) ), but generate the spec files, or whatever equivalent, from the book XML. (This last bit might be either hard or impossible; I don't know.)
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
