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

[Matt Domsch]

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
/usr/bin/cgcc
/usr/bin/sparse
/usr/share/doc/sparse-0.2
/usr/share/doc/sparse-0.2/FAQ
/usr/share/doc/sparse-0.2/LICENSE
/usr/share/doc/sparse-0.2/README

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 
/usr/include/sparse
/usr/include/sparse/allocate.h
/usr/include/sparse/bitmap.h
/usr/include/sparse/compat.h
/usr/include/sparse/dissect.h
/usr/include/sparse/expression.h
/usr/include/sparse/flow.h
/usr/include/sparse/ident-list.h
/usr/include/sparse/lib.h
/usr/include/sparse/linearize.h
/usr/include/sparse/parse.h
/usr/include/sparse/ptrlist.h
/usr/include/sparse/scope.h
/usr/include/sparse/storage.h
/usr/include/sparse/symbol.h
/usr/include/sparse/target.h
/usr/include/sparse/token.h
/usr/lib64/libsparse.a
/usr/lib64/pkgconfig/sparse.pc
/usr/share/doc/sparse-devel-0.2
/usr/share/doc/sparse-devel-0.2/LICENSE

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.

Thanks,
Matt

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