On Tue, 2006-12-05 at 15:59 -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?
> > 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?
Basically no.
The fundamental idea behind this proposal had been to
* make dependencies on static libs visible.
* Force packagers _really_ needing to link against static libs to
"BR: *-static" in their specs.
* Let packages "BR: *-devel" receive as few static libs as possible, to
avoid accidentially picking up dependencies on static libs
* Using and providing "*-devel" packages is supposed to be the nominal
case. Using and providing "*-static" packages should be considered
exceptions.
Implementation-wise this means:
* headers must be provided by "*-devel" packages
* static libs must be provided by "*-static" packages
* shared libs must be provides by "*-devel" packages
=> We need to consider at least 3 cases:
1. packages supplying shared libs only
- headers in *-devel
- shared libs in *-devel
2. packages supplying shared and static libs.
- headers in *-devel
- shared libs in *-devel
- static libs in *-static
- *-static must "Requires: *-devel = %{version}-%{release}"
3. packages supplying static libs only. Here I see approaches:
3.1
- headers in *-devel
- libs in *-devel
- *-devel "Provides: *-static = %{version}-%{release}"
IMO, this should be the nominal case.
3.2
- headers in *-static
- libs in *-static
- *-static "Provides: *-devel = %{version}-%{release}"
I would not recommend this variant.
Additional complications can arise from "shared/common files" and from
config files (E.g. some *.la's and *.pc's are not unlikely to become
problematic). They need to be looked after on a case by case basis.
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.
To me, the only legitimate reasons for _using_ static
libs in Fedora
should be technical ones. Which ones to allow should be subject of
FESCO's decision.
So far, I can only imagine two:
- Upstream doesn't provide them (Adding shared libs to a package
upstream ships static libs only, is a different issue - Often it's more
problematic than useful).
- Correct function of an applications being used by Fedora requires it.
Allowing people to _ship_ static libs in addition to shared libs is a
yet another issue. Except that it voids the "reduce Fedora bloat" aspect
of the rationale, it's not much of a technical problem for Fedora
itself, but a political issue.
> 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 Yes, FPC had voted
unanimously (all attending members voted for it. Ca.
7 out of 9 members had been present), but I don't recall if Axel had
been present.
All this took place before Ulrich Drepper jumped onto the wagon and
before the "Fedora Summit", so ...
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 :-)
Am I supposed to do so? I thought somebody was to supposed to present
this to FESCO and then he would give me a ping to merge it or he would
merge it. Anyway, no problem, I can merge it, when I can find a free
time slot.
Ralf