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