On Mar 1, 2012, at 9:32 AM, Jeremy Huntwork wrote:
> I'm saying that if you are compiling the libs and binaries, it should
> conform to the configuration of your toolchain. I say 'should'
I never said your way of building the toolchain is wrong--I haven't even
looked. I'm sure it's great. I'm also sure that it has impacts that can be
divided into two categories:
1) Not-fixable: precompiled binaries.
2) Fixable: stuff we compile ourselves.
You seem to be saying: "Okay...We break the not-fixable stuff--BUT, HEY--that's
the only thing that prevents this from being the right thing to do." That's
not true. The time it takes to identify and fix all the "fixable" stuff is
plenty of reason to wait.
Key word: "wait".
Not: delete-all-your-source.
The BIND/OpenSSL thing boils down to: yes--it's fixable. I never said
otherwise. I simply brought it up as an example of something to consider. In
that particular case, it's probably not too big of an effort--other than the
time already taken. But, you seem to be hand-waving over the fact that it will
take eyeballs and time to figure out exactly which downstream things are
broken, and then the eyeballs and time to fix those packages.
> Tabling it because of the precompiled binaries is about the only reason
> to table it. What you are suggesting is overkill - 95% of the packages
> you build will be just fine if you configure your toolchain to only use
> lib. There will be some outside cases that will try to stick stuff in
> lib64, but most of those you can just move to lib. Anything that is
> hard-coded can be discovered by a careful build process and
> re-hard-coded to a working path, but again, most everything will "just
> work".
You're point seems to boil down to: "Don't overreact. 95% of stuff will work."
And, you seem to be implying: "Meh--downstream stuff...whatever. Your
problem." Do you not see the value to other people who think: "Currently, 100%
of the stuff I care about works. I don't want to jeopardize core parts of my
system just because someone wants a cleaner build--before verifying my
downstream works."
I'm not saying you're way is wrong.
I'm advocating that due time be given to allow downstream verification. Why
not pursue a course more like: "Let's get some downstream (e.g., BLFS, CLFS)
people to see what the actual impact of my proposed changes will be to actual
consumers of LFS." Then, if downstream people say: "The impact has been
assessed, the things that need to be fixed are at least identified, (if not
already fixed), and it's all ready to rock," then--by all means, change that
f*cker. Do whatever you want to the toolchain.
You say you don't use LFS or BLFS. And, judging from your domain, you're just
using it as a cookbook to build your own OS. Let's assume you're taking
responsibility for all *your* downstream, so maybe you don't feel like it's a
big deal. But, practically speaking, as someone evaluating LFS+ for use in
production systems, I. frankly don't care that the 5% isn't a big deal to you.
I care that my downstream works. Claims like "Well, most stuff works--the
rest...is your problem," are a little carefree for me, even if they are true.
This isn't climate change; we have the luxury of being able to wait.
* * *
The whole BIND/OpenSSL example is an example of something that might take time
to at least evaluate--if not properly reconfigure before testing. And, even
though you may not care about those packages, I do. Please see this as a proxy
for other packages that other people may have concerns about. Since you don't
care, maybe you're fine with saying: "Look--I totally believe it will work as
long as the toolchain is 'properly configured' to my specifications; I swear on
my great-grandmother's grave!" That's fine; you should believe in your work.
But that doesn't mean I'm going to share that same faith without testing.
And, it's not like getting that testing is even hard. Just not sure why
'testing' seems to be a dirty word in the LFS community. BLFS packages that
have test suites are a perfect solution. See response to Andrew's email about
how testing forms a natural dividing line in BLFS, and how it could be used in
the future as a way to reduce the time it takes to merge big changes in LFS
because that subset of BLFS (the stuff that can be automatically tested) can be
viewed as a system regression test...
I'm saying that big changes should get verified--not that they shouldn't happen
at all. That's what "tabled" means. Not "thrown away." I'm sure your build
will prove to be l33t and amazing. Why not consider making your own fork of
LFS on Git, and maintaining it there while trying to drum up downstream
testers? Git would make it easy for people to pull in your changes against
their own repos. Then, when the testing has been done, *that* would be a much
more compelling fait accompli.
Q
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
