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