On Mar 5, 2012, at 4:26 PM, Ken Moffat wrote:
> On Mon, Mar 05, 2012 at 03:48:49PM -0800, Qrux wrote:
>>
>> What is the case against the default? Presumably the developer had
>> something in mind when he chose one or the other as the default.
>
> If you *really* don't know why some of us dislike static libs, I
> spelled it out just before Christmas at
TL;DR--AFAICT, as a general rule, LFS* aggregates, not develops, the packages
it uses.
1) Not liking static-libs because some people/packages (ab)use them is not
necessarily a great reason to adopt a general position on the matter.
2) Not liking static-libs because of embedding (where a downstream package
distributes its own tarballed upstream) is using a sledgehammer for a
nosebleed. Yeah, you could sharpen the handle-end, and plug the bleeding
nostril. But that doesn't seem right. The issue was with the embed, which you
want the dev to fix, not the aggregator.
Isn't it better to generally say: "Sure, we'll take what the devs offers as a
default--unless it's broken and they won't fix it. In that case, we'll step in
an offer a different default."?
* * *
It seems generally better to have upstream fix the issue (as you point out in
your next message about glibc). So, if you "release without sign-off", you're
getting in the middle. Yes, it's probably a gray area. And, yes, it might be
a necessary burden in some cases. But, does it occur so often that it requires
adopting a principle of: "Let's preempt the devs in case they do something
undesirable by always using --disable-static."?
> There is nothing wrong with static linking within a package. But,
> many years ago, there was a problem with a vulnerability in a
> library that had been included in *many* other packages. It took a
> *long* while to identify all the packages shipping copies of that
> library, and then to either patch them or change the builds to use
> the system version...
And, in your example of the zlib issue, was the issue really about
static-linking? Or about embeds (which is obviously statically-linking, but as
a "symptom", not a "disease")?
I just feel the more you deviate from the dev's defaults, the more you put
yourself in a position of continued maintenance. I didn't think LFS* was about
trying to own--or really even contribute--to its upstream. So, if you're
fixing issues (embeds or otherwise), then...Yes, you've just given yourself
more work.
And that's all without focusing on the issue that embeds are:
1) an upstream problem, and...
2) not about enable/disable static-linking.
The package should just stop using the embed. Sure, if the devs drop
maintenance, and LFS still uses it, well, then it's your problem for using it.
But, if they're still working on it, don't you generally want to let them fix
it. In the weird case of them not doing it (for whatever reason), sure, you
have to step in. But, in your zlib example, were all the various upstream devs
just being totally unresponsive to the zlib problem? Or, were you just that
far ahead of the problem that you felt it was necessary to do the work yourself?
Your example is years old (your words). I presume the zlib issue has been,
since, identified by all downstream packages, and those packages made
appropriate changes. So, you must have been pressed for time, and I'm curious
what that pressure was. Because, generally, I figured this was something LFS*
prefers to avoid, rather than get in the middle...
You have to figure that most package maintainers have _also_ learned that same
lesson; e.g., Perl devs realizing: "Oh, zlib _can_ have security implications,
maybe use system zlib and stop embedding zlib so we don't have to track these
problems. And, you also have to figure that even after having learned that
lesson, some still choose to either embed or statically-link, because they see
a good reason.
So, if LFS* lacks a good reason to deviate, why take a default position that
deviates?
Q
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
