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.
-- Pat
On Sat, Jun 02, 2007 at 07:58:06PM +0200, Patrice Dumas wrote:
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.
I like it. :)
"PD" == Patrice Dumas pertusus@free.fr 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 can get behind this. I have no problem with us shipping static libraries if it helps the users as long as we're not shipping statically linked programs. However, we certainly shouldn't try to "sell" static linking as a general solution, and I don't think this draft does.
These two paragraphs can't just be pasted into the existing guidelines, however, as that would result in a somewhat contradictory text. I'd like to see the complete "Exclusion of Static Libraries" section (which will probably need a rename to continue making sense) before we vote on anything.
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.
- J<
On Sat, Jun 02, 2007 at 01:59:41PM -0500, Jason L Tibbitts III wrote:
"PD" == Patrice Dumas pertusus@free.fr 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.
I think this is nice OTOH, but difficult to foresee OTOH. Some libs are quite easy to identify as scientific/numeric consumable, but other non-numeric ones can also be required for the numerical application.
"AT" == Axel Thimm Axel.Thimm@ATrpms.net 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.
- J<
On Sat, Jun 02, 2007 at 04:08:32PM -0500, Jason L Tibbitts III wrote:
"AT" == Axel Thimm Axel.Thimm@ATrpms.net 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.
The problem is that the packager of libfoofastmem may not know that building the unpackaged supernumberbar and bazcrunch requires libfoofastmem. E.g. the people that know where a static lib is needed are not the packagers, but the consumers.
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.
The packager of libfoofastmem may not be interested in any numeric stuff at all, he may need libfoofastmem for a fuse tmpfs module and not ever having thought about other consumers. E.g. the knowledge to document the use of static libs implies that reverse build dependencies of unpackaged software are known to the consumed party, which must not be the case.
"AT" == Axel Thimm Axel.Thimm@ATrpms.net 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.
- J<
On Sat, Jun 02, 2007 at 04:24:07PM -0500, Jason L Tibbitts III wrote:
"AT" == Axel Thimm Axel.Thimm@ATrpms.net 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.
Yes, that's correct.
Either the packager knows the static library is needed, or someone's going to have to tell them it's needed.
Let's try this that way, e.g. act on demand. Maybe that should be briefly mentioned in the guideline as well: If users notice that they require a static lib they should contact the maintainer and give the reason both for the maintainer to decide, as well as for the comment.
On Sat, Jun 02, 2007 at 01:59:41PM -0500, Jason L Tibbitts III wrote:
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.
I think it should be in order, but I don't think it deserves to be said especially for this case, since in my opinion everytime there is deviation from the guidelines it should be explained in a comment.
-- Pat
On Sat, 2007-06-02 at 19:58 +0200, Patrice Dumas wrote:
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.
-1
1. This proposal is not in the distro's interest, because it causes additional bloat.
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.
Ralf
On Sun, Jun 03, 2007 at 10:02:39AM +0200, Ralf Corsepius wrote:
-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.
- 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.
-- Pat
On Sun, 2007-06-03 at 12:02 +0200, Patrice Dumas wrote:
On Sun, Jun 03, 2007 at 10:02:39AM +0200, Ralf Corsepius wrote:
-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.
- 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?
<cite> * in the case of user compiled programs doing numerical computations or data analysis, using static libraries may be useful. </cite>
You are explicitly referring to numerical computation or data analysis.
This is silly.
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.
No idea what FESCO did, if they agreed to it, they failed.
Ralf
On Sun, Jun 03, 2007 at 01:32:06PM +0200, Ralf Corsepius wrote:
This issue is addressed by the new paragraph, isn't it?
<cite> * in the case of user compiled programs doing numerical computations or data analysis, using static libraries may be useful. </cite>
You are explicitly referring to numerical computation or data analysis.
This is silly.
That's because these are the cases where static libs may be usefull and shared libs are not needed.
No idea what FESCO did, if they agreed to it, they failed.
The ratified http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryChanges
unless I am wrong (not my paragraph).
-- Pat
packaging@lists.fedoraproject.org
-
Axel Thimm -
Jason L Tibbitts III -
Patrice Dumas -
Ralf Corsepius