Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Fedora Packaging (http://www.linux-archive.org/fedora-packaging/)
-   -   Another clarification of the static library packaging guidelines (http://www.linux-archive.org/fedora-packaging/393185-another-clarification-static-library-packaging-guidelines.html)

Jeroen van Meeuwen 06-30-2010 05:30 PM

Another clarification of the static library packaging guidelines
 
"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
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

"Richard W.M. Jones" 07-06-2010 08:53 AM

Another clarification of the static library packaging guidelines
 
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.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

"Richard W.M. Jones" 07-06-2010 09:09 AM

Another clarification of the static library packaging guidelines
 
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.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

"Richard W.M. Jones" 07-06-2010 09:33 AM

Another clarification of the static library 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.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

"Richard W.M. Jones" 07-06-2010 03:22 PM

Another clarification of the static library packaging guidelines
 
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.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://et.redhat.com/~rjones/libguestfs/
See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

"Richard W.M. Jones" 07-06-2010 05:55 PM

Another clarification of the static library packaging guidelines
 
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.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging


All times are GMT. The time now is 09:36 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.