Hello, Here is an updated version of the paragraph about shipping static numerical libs taking into account the comments on the first version. The objective is to have this included in http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryChanges at the end of 'Packaging Static Libraries'. * in the case of user compiled programs doing numerical computations or data analysis, using static libraries may be useful. Indeed it allows to build static executables that have more chance to be run on other platforms than the box they were compiled in, that have different dynamic library versions or even that don't have the library installed at all. At the same time those applications, in general, don't need the features brought in by shared libraries (no need for nss, no security issue, no need for iconv...). Therefore it may be acceptable or even desirable to ship static libraries for numerical and data processing libraries to help users needing to link statically their locally compiled executables. The static libraries still need to be in separate sub-packages and this doesn't means that the executables packaged in Fedora should be link statically, this is only for users linking locally their own programs. Some packagers feel that this is not the right solution for locally compiled programs portability, since it is not general (doesn't work with nss, iconv...). However a general solution doesn't seems to exist yet.

>>>>> "PD" == Patrice Dumas <pertusus(a)free.fr&gt; writes: PD> Here is an updated version of the paragraph about shipping PD> static numerical libs taking into account the comments on the PD> first version. I also wonder if it would be appropriate to include a statement that package submitters should explain in the spec the reason why static libraries are being packaged.

>>>>> "AT" == Axel Thimm <Axel.Thimm(a)ATrpms.net&gt; writes: AT> I think this is nice OTOH, but difficult to foresee OTOH. Well, at some point you have to know you need a static library, because you'll put the necessary bits in the spec to make it happen.

I see no reason a comment explaining the need couldn't be added at that time. And if someone doesn't know that the static library is needed, it probably shouldn't be packaged.

>>>>> "AT" == Axel Thimm <Axel.Thimm(a)ATrpms.net&gt; writes: AT> The problem is that the packager of libfoofastmem may not know AT> that building the unpackaged supernumberbar and bazcrunch requires AT> libfoofastmem. E.g. the people that know where a static lib is AT> needed are not the packagers, but the consumers. That line of reasoning leads to us shipping every static library we possibly can, just because something we don't know about might use it.

Either the packager knows the static library is needed, or someone's going to have to tell them it's needed.

Hello, Here is an updated version of the paragraph about shipping static numerical libs taking into account the comments on the first version. The objective is to have this included in http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryChanges at the end of 'Packaging Static Libraries'. * in the case of user compiled programs doing numerical computations or data analysis, using static libraries may be useful. Indeed it allows to build static executables that have more chance to be run on other platforms than the box they were compiled in, that have different dynamic library versions or even that don't have the library installed at all. At the same time those applications, in general, don't need the features brought in by shared libraries (no need for nss, no security issue, no need for iconv...). Therefore it may be acceptable or even desirable to ship static libraries for numerical and data processing libraries to help users needing to link statically their locally compiled executables. The static libraries still need to be in separate sub-packages and this doesn't means that the executables packaged in Fedora should be link statically, this is only for users linking locally their own programs. Some packagers feel that this is not the right solution for locally compiled programs portability, since it is not general (doesn't work with nss, iconv...). However a general solution doesn't seems to exist yet.

On Sun, Jun 03, 2007 at 10:02:39AM +0200, Ralf Corsepius wrote: > > -1 > > 1. This proposal is not in the distro's interest, because it causes > additional bloat. I forgot to add that, I'll do another try later. > 2. This proposal's focus on "numerical libs" is silly. > It tries to implement a special exception into the FPC based on an > application domain, while the problem actually is application domain > independent. > > The real problem is: Cross-distro packaging of local packages, which > some people (bogusly) try to approach static linkage. This issue is addressed by the new paragraph, isn't it?

Anyway I don't care about not having it in the guidelines, I can put it in my personal page in the wiki (although such thing doesn't exist yet). It is not really an exception, since this exception is already accepted since FESCO ratified the original proposal (unless I missed something). It is more a precision.