On Wed, 2006-12-06 at 00:32 +0100, Axel Thimm wrote:
On Tue, Dec 05, 2006 at 04:34:28PM -0600, Matt Domsch wrote:
> 1) need -devel have a Requires: %{name}-%{version}-${release} if that
> doesn't include a shared library? I wouldn't think so, but it's a
> "Must" in the guidelines.
What's in the %{name} package?
> 2) need I create a -static package for the static library?
>
Yes.
> 3) if yes, should -static have a Requires:
> %{name}-devel-%{version}-%{release}? Should this go in the
> recommendations for all -static packages?
I would think yes. Does anyone see a problem with doing that?
You also need to writeup your reasons for having a static library in the
first place and presenting it to FESCo. The fact that Jeff Garzik wants
to use it is a two edged sword -- on the one hand it means there is a
need for the library. OTOH, it means that the library is going to be
used by multiple programs which is what leads to the security and other
problems.
The use of -static package names is supposed to help us deal with this
but we know it's not a complete job.
Jeff's comment that maybe the library is special and shouldn't be
subjected to the same ABI tests as the majority of libraries has merit.
But we don't have any guidelines in place for that... I don't think we
even have guidelines that forbid having that kind of ABI unstable
library in the first place.
static subpackages have been discussed a bit in the recent past, but
not by the packaging group. IMHO they make sense if static libs are to
be part of the build for whatever reason, but we don't have any rules
about it, not even about the naming, e.g. whether it should be called
foo-static, foo-devel-static, foo-static-devel and so on. At any rate
the "static" subpackage would have to require the conventional devel
package to get access to the headers, so 3) above goes w/o saying.
But first we would need to decide on how to handle static content in
general, e.g. first decide on subpackaging it and then how the
packages are to be handled.
Just to catch any such discussion beforehand: *Whether* something
needs to be statically linked or not, is a policy that is not decided
by the packaging committee - we just consider the *how*s and let the
*why*s to fesco and core. ;)
To cut a long story short: Matt, if you do need a static lib, do as
you please for now - we need to sort it out first, and then we'll tell
you that it needs to be done differently ;)
Actually, I think we voted on this:
http://fedoraproject.org/wiki/PackagingDrafts/StaticLinkage
My memory is backed up by the status on:
http://fedoraproject.org/wiki/Packaging/GuidelinesTodo
Ralf just needs to move the document into the Packaging tree and update
the Guidelines in the proper places :-)
-Toshio