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
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
