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