There are dozens of -devel packages, which contain static libs only, but don't provide a virtual -static package.
Many of them are OCaml (ocaml-*) and Haskell (ghc-*) packages.
The Haskell packaging guidelines contain a section that seems to suggest that the packages need not provide a virtual -static package: https://fedoraproject.org/wiki/Packaging:Haskell#Static_vs._Dynamic_Linking
What about OCaml? https://fedoraproject.org/wiki/Packaging:OCaml is not mentioning static libraries at all.
What other exceptions exist?
On 06/30/2010 10:09 AM, Michael Schwendt wrote:
There are dozens of -devel packages, which contain static libs only, but don't provide a virtual -static package.
Many of them are OCaml (ocaml-*) and Haskell (ghc-*) packages.
The Haskell packaging guidelines contain a section that seems to suggest that the packages need not provide a virtual -static package: https://fedoraproject.org/wiki/Packaging:Haskell#Static_vs._Dynamic_Linking
What about OCaml? https://fedoraproject.org/wiki/Packaging:OCaml is not mentioning static libraries at all.
What other exceptions exist?
Tcl allows static 'stub' libraries in the -devel subpackage. See the last paragraph here:
https://fedoraproject.org/wiki/Packaging/Tcl
--Wart
On Wed, 30 Jun 2010 10:14:39 -0700, Michael Thomas wrote:
Tcl allows static 'stub' libraries in the -devel subpackage. See the last paragraph here:
That removes tcl-tclxml and tkimg, albeit on the assumption that a package with "tk" at the beginning of its name and "stub" in its static library names, is a Tk package.
On 06/30/2010 10:37 AM, Michael Schwendt wrote:
On Wed, 30 Jun 2010 10:14:39 -0700, Michael Thomas wrote:
Tcl allows static 'stub' libraries in the -devel subpackage. See the last paragraph here:
That removes tcl-tclxml and tkimg, albeit on the assumption that a package with "tk" at the beginning of its name and "stub" in its static library names, is a Tk package.
It also removes tdom, memchan, and itcl, which were never converted to the proper Tcl package naming guidelines.
--Wart
On Wed, 30 Jun 2010 11:01:06 -0700, Michael Thomas wrote:
On 06/30/2010 10:37 AM, Michael Schwendt wrote:
On Wed, 30 Jun 2010 10:14:39 -0700, Michael Thomas wrote:
Tcl allows static 'stub' libraries in the -devel subpackage. See the last paragraph here:
That removes tcl-tclxml and tkimg, albeit on the assumption that a package with "tk" at the beginning of its name and "stub" in its static library names, is a Tk package.
It also removes tdom, memchan, and itcl, which were never converted to the proper Tcl package naming guidelines.
Urks. :) Got them. Looking for /tcl in the library path should be safe. tdom, on the other hand, resides in %_libdir, so currently I'm ignoring it based on its tiny file size plus "stub" in its name.
Michael Schwendt wrote, at 07/01/2010 02:09 AM +9:00:
There are dozens of -devel packages, which contain static libs only, but don't provide a virtual -static package.
What about OCaml? https://fedoraproject.org/wiki/Packaging:OCaml is not mentioning static libraries at all.
I am not familiar with OCaml but the above guideline says that "OCaml does not support dynamic linking of binaries".
Regards, Mamoru
On Thu, 01 Jul 2010 02:26:52 +0900, Mamoru wrote:
There are dozens of -devel packages, which contain static libs only, but don't provide a virtual -static package.
What about OCaml? https://fedoraproject.org/wiki/Packaging:OCaml is not mentioning static libraries at all.
I am not familiar with OCaml but the above guideline says that "OCaml does not support dynamic linking of binaries".
Okay. Hopefully all of them are in the "ocaml-" namespace. I've extended the package name check to look for "ocaml-" also in the middle of package names, and that has closed two tickets.
On Thu, Jul 01, 2010 at 02:26:52AM +0900, Mamoru Tasaka wrote:
Michael Schwendt wrote, at 07/01/2010 02:09 AM +9:00:
There are dozens of -devel packages, which contain static libs only, but don't provide a virtual -static package.
What about OCaml? https://fedoraproject.org/wiki/Packaging:OCaml is not mentioning static libraries at all.
I am not familiar with OCaml but the above guideline says that "OCaml does not support dynamic linking of binaries".
That statement is confusing and untrue - I didn't want to add it to the original guidelines.
OCaml supports dynamic linking to C code and always has, and it is always used, eg:
$ ldd /usr/bin/virt-top linux-vdso.so.1 => (0x00007fff891e8000) libvirt.so.0 => /usr/lib64/libvirt.so.0 (0x0000003fc8000000) libncursesw.so.5 => /lib64/libncursesw.so.5 (0x00000035f4c00000) libm.so.6 => /lib64/libm.so.6 (0x00000035f3000000) [etc]
OCaml < 3.11 didn't support dynamic linking to *natively compiled* OCaml libraries (only to ones compiled as bytecode).
Since OCaml 3.11, both native and bytecode dynamic linking are fully supported.
However even with 3.11 we still don't commonly dynamically link to native OCaml libraries. Because it's a new feature, this requires a very large upstream, toolchain and packaging effort, even assuming that it's worth doing at all. OCaml libraries don't suffer the sorts of common security bugs which so frequently affect C libraries, and C libraries have always been dynamically linked, plus there are a lot fewer pure OCaml libraries around.
The effect of this is that for OCaml *programs* (not libraries) if there was ever a security bug in a dependent pure OCaml library, we would need to recompile both the library and the program. Other libraries wouldn't be affected, because those don't contain the code of the dependency.
There has never been a security bug related to OCaml code in an OCaml library, and only two security bugs related to OCaml packages at all: one was to some C code in ocaml-camlimages [package now defunct] and another was insecure /tmp handling in the coccinelle program.
Rich.
"Michael Schwendt" mschwendt@gmail.com wrote:
There are dozens of -devel packages, which contain static libs only, but don't provide a virtual -static package.
Many of them are OCaml (ocaml-*) and Haskell (ghc-*) packages.
The Haskell packaging guidelines contain a section that seems to suggest that the packages need not provide a virtual -static package: https://fedoraproject.org/wiki/Packaging:Haskell#Static_vs._Dynamic_Linking
What about OCaml? https://fedoraproject.org/wiki/Packaging:OCaml is not mentioning static libraries at all.
What other exceptions exist?
Where did these exceptions come from?
I for one would argue that, just to preserve some sort notion of consistency across packages, such exceptions to the general packaging guidelines should not be allowed.
-- Jeroen
On Wed, Jun 30, 2010 at 07:09:54PM +0200, Michael Schwendt wrote:
What about OCaml? https://fedoraproject.org/wiki/Packaging:OCaml is not mentioning static libraries at all.
The *.a files in ocaml-*-devel aren't C code at all. They contain machine code compiled from OCaml sources.
This is mentioned specifically in the guidelines above so I don't see how it's a problem.
Rich.
On Tue, 6 Jul 2010 09:53:45 +0100, Richard wrote:
What about OCaml? https://fedoraproject.org/wiki/Packaging:OCaml is not mentioning static libraries at all.
The *.a files in ocaml-*-devel aren't C code at all.
What has talked about C code?
They contain machine code compiled from OCaml sources.
*confused* Then there is no difference compared with libs compiled from C (or C++ or other programming languages, which are compiled into native code). So, why do you mention C?
This is mentioned specifically in the guidelines above so I don't see how it's a problem.
The Wiki page about OCaml,
https://fedoraproject.org/wiki/Packaging:OCaml
does not mention "static" libraries at all. Hence there must some sort of implicit exception with regard to the packaging guidelines.
On Tue, Jul 06, 2010 at 11:23:07AM +0200, Michael Schwendt wrote:
*confused* Then there is no difference compared with libs compiled from C (or C++ or other programming languages, which are compiled into native code). So, why do you mention C?
Well C/C++ code suffers from several classes of error which don't affect other languages, and this is what makes static linking particularly undesirable for C libraries. The other reason for avoiding static linking -- avoiding duplication of code -- happens anyway in C libraries (think: headers/inlining), and even more so in the OCaml compiler which does cross-module inlining when possible.
Anyway, see my other reply for more details about what OCaml is doing.
Rich.
Michael Schwendt wrote:
The Wiki page about OCaml,
https://fedoraproject.org/wiki/Packaging:OCaml
does not mention "static" libraries at all. Hence there must some sort of implicit exception with regard to the packaging guidelines.
In case no one has noticed yet, OCaml programs have an explicit exception to the static linkage guideline with regard to linking against (only) OCaml libraries.
https://fedoraproject.org/wiki/Packaging/Guidelines#Programs_which_don.27t_n...
On Tue, 06 Jul 2010 08:58:13 -0500, Garrett wrote:
The Wiki page about OCaml,
https://fedoraproject.org/wiki/Packaging:OCaml
does not mention "static" libraries at all. Hence there must some sort of implicit exception with regard to the packaging guidelines.
In case no one has noticed yet, OCaml programs have an explicit exception to the static linkage guideline with regard to linking against (only) OCaml libraries.
https://fedoraproject.org/wiki/Packaging/Guidelines#Programs_which_don.27t_n...
It's sort of misplaced or "well hidden".
It is an exception to the "Staticly Linking Executables" guidelines, not to the "Packaging Static Libraries" guidelines. The former is about linking with .a files, the latter is about -static subpackages. Not having to notify FESCo related to linking with .a files sort of seems to imply that it isn't necessary to create -static subpackages. Hey! ;-)
Maybe we can take a step back here and ask: why is this such a problem?
The guidelines are quite moderate in their tone. They say:
"Packages including libraries should exclude static libs as far as possible (eg by configuring with --disable-static). Static libraries should only be included in exceptional circumstances. Applications linking against libraries should as far as possible link against shared libraries not static versions. [...] In general, packagers are strongly encouraged not to ship static libs unless a compelling reason exists."
However the tone of this thread is extreme. Any *.a file must apparently never appear anywhere outside a *-static package, no matter what, even if it's been like this forever (eg. libgcc.a, libiberty, etc) or even if it's not causing a problem for anyone (OCaml code).
This isn't even about static code specifically, because no one's talking about static copies of inline code from header files, which is just as well because C uses that all over the place, and C++ even more so, and none of that is confined to -static packages, far from it.
If there's an actual problem that we're solving, let's hear about that.
Rich.
PS. On the separate subject of OCaml packages, the whole pkg / pkg-devel split doesn't suit OCaml code at all, and is at best a hack to make OCaml packages look a bit like C libraries. Given the choice and lots of spare time we'd use a radically different naming system.
On Tue, 6 Jul 2010 16:22:50 +0100, Richard wrote:
Maybe we can take a step back here and ask: why is this such a problem?
With "this" == what?
I've asked about exceptions to the static library packaging guidelines. This has lead to helpful replies, such as those about Tcl/Tk stub libs. The bz tickets filed about those packages have been closed automatically.
The guidelines are quite moderate in their tone. They say:
"Packages including libraries should exclude static libs as far as possible (eg by configuring with --disable-static). Static libraries should only be included in exceptional circumstances. Applications linking against libraries should as far as possible link against shared libraries not static versions. [...] In general, packagers are strongly encouraged not to ship static libs unless a compelling reason exists."
However the tone of this thread is extreme.
Ah, come on! It isn't extreme just because you call it extreme. :-( Can you quote a piece you consider "extreme"?
Any *.a file must apparently never appear anywhere outside a *-static package, no matter what, even if it's been like this forever (eg. libgcc.a, libiberty, etc) or even if it's not causing a problem for anyone (OCaml code).
Well, if we have guidelines _and_ exceptions to them, we [=> FESCo or the packaging committee] should choose between either one for every package in the collection. And honestly, I don't understand yet what "problem" you refer to.
Michael, I'm on the defensive here because I've poured a huge amount of work == time into getting OCaml packages into Fedora, to the stage where we are almost now competitive with Debian. So I get defensive about this.
I got an email saying that a package was "violating the Static Packaging Guidelines", and there's another email in this thread (from kanarip, not you) saying "such exceptions to the general packaging guidelines should not be allowed".
The issue I'm talking about is ...
On Tue, Jul 06, 2010 at 05:58:17PM +0200, Michael Schwendt wrote:
With "this" == what?
... Is separating out static code into -static packages (a) useful (b) possible (c) something that should be applied to code other than unsafe compiled languages like C/C++?
(a) Useful: Yes for making it possible to do security updates quickly.
(b) Possible: For a lot of code. But not for inlined code.
(c) Applied to non-C/C++: In the best of all worlds yes, but in reality this has not been a problem for OCaml code.
I've asked about exceptions to the static library packaging guidelines. This has lead to helpful replies, such as those about Tcl/Tk stub libs. The bz tickets filed about those packages have been closed automatically.
Indeed, and I fully support your aims of making the QA of packages as automatic as possible, and even of automatically opening bugs. If it seems like I didn't, then that wasn't intended and I'm sorry about that.
Rich.
On Tue, 6 Jul 2010 18:55:42 +0100, Richard wrote:
Michael, I'm on the defensive here because I've poured a huge amount of work == time into getting OCaml packages into Fedora, to the stage where we are almost now competitive with Debian. So I get defensive about this.
I got an email saying that a package was "violating the Static Packaging Guidelines",
It would be less destructive, if you would point out false positives and preferably give hints on how to avoid them, instead of trying to fight needlessly. Let's see:
Do you refer to "cduce"? (Summary: Modern XML-oriented functional language)
cduce : does not adhere to Static Library Packaging Guidelines https://bugzilla.redhat.com/609600
| cduce-devel | contains only static libraries, | but no virtual -static package is provided
It isn't in the "-ocaml" namespace, so a closer look is necessary. The libs are stored below %_libdir/ocaml/ which might be a sufficient detail to ignore any such packages.
So, my resulting question is: Are there other packages with .a libraries compiled with OCaml, which cannot be recognised based on the path name?
packaging@lists.fedoraproject.org