[Fedora-packaging] static subpackages (was: sparse 0.2, headers and static lib)

Matt Domsch Matt_Domsch at dell.com
Wed Dec 6 04:44:18 UTC 2006

On Tue, Dec 05, 2006 at 03:59:32PM -0800, Toshio Kuratomi wrote:
> 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?

$ rpm -qpl sparse-0.2-1.x86_64.rpm

i.e. no libsparse.so, and nothing that a -devel package needs.  So I
don't see the need for a dependency here.

> > > 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?

So 3 is yes, no real problem there.  Here's what -devel provides:

$ rpm -qpl sparse-devel-0.2-1.x86_64.rpm 

but I'll move libsparse.a into its own -static package.

> 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.

as noted, it's not a big security concern for this development app usage.
> 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.

It's the instability of the API/ABI that keeps the project from
wanting to expose a versioned shared library.  That's more work than
it's ready to maintain; Jeff's fine with it being fluid and changing
his own app accordingly.  I hadn't packaged the shared lib in earlier
versions because nothing else needed it; now that something does, that
doesn't mean the API needs to be versioned, except that shared libs
would require that overhead.


Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

More information about the Fedora-packaging mailing list