On Mar 1, 2012, at 10:40 AM, Andrew Benton wrote:
> On Thu, 1 Mar 2012 08:43:05 -0800
> Qrux <qrux....@gmail.com> wrote:
>
>> [~/lfs/src/openssl-1.0.0e] # grep ENGINESDIR $(find . -name "*.c" -o -name
>> "*.h")
>> ./crypto/engine/eng_list.c: if((load_dir =
>> getenv("OPENSSL_ENGINES")) == 0) load_dir = ENGINESDIR;
>> ./crypto/opensslconf.h:#define ENGINESDIR "/usr/lib64/engines"
>
> This is not the same in my openssl-1.0.0e tarball
That is not the point.
I'm perfectly aware that the lib64 references come *after* running config. I
said so, but I guess that got lost in the all the rest of the words. And, the
point isn't that it's not fixable. If you can grep for it, it implies you can
fix it. So, regardless of whether it's there before or after running .config,
the fact that it generates non-binary output means we can fix it. In fact, as
long as you have the sources to begin with, you can fix it. It's not about
whether or not it's "fixable".
The point is the time.
It takes time to figure these things out. This one small issue--originally
intended as a potential alert to the impact that these changes might have--has
already involved 3 people and several hours. That's...what? Over $1,000 worth
of time spent? I'm not ready to subject working downstream to possible
breakage because someone wanted a cleaner build. I'm advocating testing before
going ahead. I'm not sure why there's so much opposition to it. BLFS can be
viewed as essentially a huge piece of testing infrastructure for LFS. Why not
leverage it to help test? Then, when things work, by all means--go ahead with
the updates.
A while back, I advocated breaking BLFS into (at least) 2 pieces. There are
core parts of system that should get tested and verified. Things like OpenSSL
fall into this category, even if they aren't in LFS, to help ensure that LFS is
"good." I can't really think of many other things that are so essential--and
essential to verify. A large part of that motivation was to allow for more
aggressive testing of things "closer to the core". Things like OpenSSL (hell,
even BIND) are well-worth using as barometers of whether or not large-scale
changes are going to break other things downstream (I'm sure there are others;
let's not get mired in that).
I'm sure JH's stuff "works" insofar as he's tested things. But that doesn't
mean I'll jump on a bandwagon without getting verification for my own
downstream. If 100% of the stuff I care about works right now, why would I
give that up? See next message for more of the same...
Q
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
