On Wed, 2006-10-04 at 10:45 -0500, Rex Dieter wrote: > Ralf Corsepius wrote: > > > Static linkage against dietlibc, IMO is nothing but a script-kiddy's > > attempt to "pimping Linux". There should not be any room for such > > undertakings. > > Extend that logic a little, and we shouldn't allow dietlibc in Extras at > all. Yes, but it might surprise you, the more I think about it, the more Iam not uncertain about this, because this problem actually consists of several pretty far fetching issues: 1. "circumventing glibc-calls by syscall-wrappers" 2. "static linkage" AFAIK, dietlibc does 1) by applying 2), several application do the same by using local files. Though I consider both ways to be "pretty stupid", one will always find people trying to outsmart themselves this way for various reasons (speed, size, security, portability). Here, having a central library (such as dietlibc) would still be preferable instead of these people starting to ship local copies of individual libc-functions. This consideration however leads to a 3rd issue: To bring this into a maintainable form, we would have to find a way to denote dependencies on specific versions of static libs into individual rpms, which can be applied to check for version updates of static libs rsp. are supposed to break upon updates of static libs. (At minimum something like: BR: dietlibc-static = version-release, or even more radically, require all static libraries to provide a virtual provide a libxxxx_a(..) = version-release, which all packages using this static lib must Require:) > Either dietlibc OK for Extras and for Extras pkgs to link-against/use it, or > not. I am in favor of changing the GuileLines to require *-static (which would require dietlibc to be renamed) and to require someones explicit permission on any case of static linkage. > ATM, I'm personally leaning toward the former, especially in cases > where upstream and the packager/maintainer prefer using dietlibc. As I wrote before, in most cases, a decision on trade-offs and a balance between "pimping" and "maintainability" has to be found. Some packagers/maintainers apparently are "keen on pimping Linux at any price" - I am not willing to be playing it nice to them. In addition to all this, another issue has popped up, which IMO renders shipping static libs as part of Fedora very questionable (to say the least) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209316 Ralf -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
