On Feb 29, 2012, at 12:30 PM, Andrew Benton wrote:
> It was me that put that in the BLFS page. Thanks for your email to BLFS
> dev about the problem with Bind.
Why did we go in this circle?
I said BIND needed, minimally, a symlink at /lib64 to work. I realize that
that case is somewhat minor, but it's suggestive that certain downstream apps
might care about the layout of dirs/links, and some more than BIND. You fixed
it in the book yourself, but then said: "No, BIND is fine." Yet, the only
platform it needs that link on is pure-64bit. Rinse, lather, repeat.
Maybe there's some confusion about why I brought up BIND...
In principle, I love *clean*, (and would love it if everything were 64-bit
already), but protecting old executables is AGoodThing(TM) unless we know for
certain there are either static or up-to-date counterparts (or until the
tradeoff of supporting those old execs becomes too burdensome). I thought BIND
was a reasonable--if not small--example of why it may not be good to change the
status quo just yet.
* * *
I've noticed that from time to time, issues get brought up like this: "Thing
(A) has a problem. It's somewhat trivial (and we may already know the
solution)." The implication seems clear enough: there may be a general issue
that needs to be considered, because it might involve more than Thing (A).
Yet, unfortunately, conversations seem to fork unnecessarily into long
digressions about the scope of the original problem with (A), instead of
focusing on it as just another (perhaps trivial) data point pointing to the
general issue.
BIND is a small example. Someone brought up Xen. Someone brought up
precompiled stuff. Someone brought up games. I would add 3rd party hardware
drivers and control programs that might be dynamically linked (personally,
games don't matter so much to me, but devices do). I use some 3ware/LSI stuff
that has executables; fortunately, their stuff is statically linked. But, it
suggests that *other* things out in the wild might care (let's not focus on the
fact that my executable is actually static, but as being representative of a
class of things out there, some members of which may exhibit the actual
problem).
Q
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page