On May 20, 2012, at 1:58 PM, Jeremy Huntwork wrote:
> On 5/20/12 3:10 PM, Bruce Dubbs wrote:
>>> 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.
>>
>> I agree with this. I am updating vim in BLFS to add current patches and
>> do not like all the xorg dependencies in vim. Others may want gvim.
>>
>> There are a lot of decisions that must be made in BLFS about
>> dependencies. It's difficult to provide a package manager that does not
>> take away the user's choices.
Couldn't agree more.
For instance, SuSE wants Xorg for python, which I only needed for Xen.
> I think perhaps the point is being missed here.
Couldn't agree more with this, too.
I don't feel it's conflicting to have a system where you can take LFS a a base,
and then build on top of it.
This situation seems to really speak to git, where it's easier to branch
off--and to decentralize, because any project based on LFS obviously still
needs the "trunk", but would allow "addons"--stuff like JH's sysroot build and
also the current package management concepts--to get explored, without always
sounding the alarm bells of whether or not it's violating the book.
> So there is no threat here to what LFS or BLFS currently is. I
> absolutely agree that choice of optional dependencies should be left
> completely to user discretion.
>
> A decision about how to build a binary (and provide a spec file) for use
> by other developers should be based completely, then, on what is useful
> for developing BLFS.
Totally agree here. I think people are seeing LFS "addons" as being in
conflict with the book, and that's probably not the case.
The issue seems to be that there's no way for people to build "addons" with
either centralized control (official repo signoff) or distributed development
(fork it, because it's not a big deal to fork).
Q
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
