On Fri, Apr 20, 2007 at 11:01:35AM +0200, Ralf Corsepius wrote:
On Fri, 2007-04-20 at 10:14 +0200, Patrice Dumas wrote:
> Hello,
>
> In the guidelines it is said that static libs subpackages should be
> called *-static. This triggers lots of rpmlint warnings so I currently
> use (and propose in reviews) *-static-devel. Should I revert to *-static?
> If *-static-devel is acceptable, maybe it could be said so in the
> guidelines.
The naming "*-static" in the guidelines had been used as synonym and
short-cut for what you seem to prefer to call "*-static-devel", because
it's considered redundant and because there rarely is any need to
provide both static and dynamically linked versions of the same
applications. Even if such case should really exist (I am not aware of
any such case), one could always resort to package these apps into
differently named package.
I am not speaking about applications but libs. For example imagine there
is the library foo, and for a valid reason I want to package foo as a
static lib, not only as a shared lib. My question is can I put libfoo.a
in a subpackage called
foo-static-devel
or has it to be called
foo-static
(in this scenario, there is alread a foo-devel package with .pc, .so
symlinks and headers, and a foo package or a foo-libs with shared libs and
maybe data and executables and so on).
> Also, unless I am wrong on that point, maybe in the guidelines
there could
> be a note that when there is only static libraries there is no need of
> static subpackage and the static libs may be in -devel.
Definitely no. This contradicts the basic intentions of the '*-static'
rules in the guidelines.
One essential intention had been to make "packages that need static
linkage" distinguishable from "package that accidentally link static" at
the rpm-level.
I.e. if a package only supplies static libraries, the "correct approach"
would be to package them into *-devel but to let the package also
Provide: *-static = %{version}-%{release}
Ok. Maybe this could be in the guideline? At least I have a package that
doesn't follow that rule, maybe there are more.
And same question than above, instead of
Provide: *-static = %{version}-%{release}
could it be
Provide: *-static-devel = %{version}-%{release}
Packages "simply using these libs" then would have to
BuildRequires: *-devel
=> They would receive those libs the package contains (normally only the
dynamic ones)
Ok.
Packages "intentionally linking static" then would have to
BuildRequires: *-static
=> They would receive the ability to link statically.
I don't think that there should be any package in the fedora collection
needing this. (But there are cases when user should be able to link
against static libs, a prominent case -- my case -- being numerical
models).
--
Pat