On Fri, 2007-04-20 at 11:35 +0200, Patrice Dumas wrote:
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
The guidelines intention is to recommend "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 consider you are strong encouraged not
to ship the static libs and
to require FESCO approval.
If I was to decide, I would reject any static library unless a pressing
need of requiring a static lib can be demonstrated (!).
> > 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}
What for?
*-static is supposed to be what you seem to prefer to call "*-static-devel".
The difference is just the name.
> 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.
Exactly ... I can't imagine any.
(But there are cases when user should be able to link
against static libs, a prominent case -- my case -- being numerical
models).
You know my opinion on this argument of yours: You are abusing Linux.
Ralf