On 6/27/05, Mike Hearn <mike@xxxxxxxxxx> wrote: > Nope, probably not, and bundling private libstdc++.so versions is likely > to be the route we'll take. That's a shame because it's 3mb of overhead > most apps don't want, but if there's no other way then so be it. I find that argument about statically linking... satisifyingly ironic... considering part of you argument for installing it by default is that users don't really caring about a a few 3 mb compatibility packages on the system here or there. I think you should probably avoid arguments reference when 'most' 3rd party vendors or 'most' users want. I think 'most' of the people watching the conversation probably agree that neither of us is in a good position to know the desires of 'most' of either population. > Well, the whole point of soname versioning and renaming the library when > it changes its exported interface is so they can be parallel installed. I > don't think it's too much to ask that it's installed by default which is > definitely a downstream decision. We disagree. Some libraries are unstable, and I think software vendors should be responsible for doing their own due diligence about what to expect in terms of promised stability of the interface BEFORE they decide to link dynamically to a library. Since this whole 'platform' idea seems to be your cup of tea, perhaps you can make a summary list of which libraries have a commitment by the upstream project for ABI and API stability as a guide to 3rd party software vendors to use to make decisions about what to dynamically link against. -jef -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-devel-list
