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