satic libs package naming

[Patrice Dumas]

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.

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.

--
Pat

[Ralf Corsepius]

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.

>  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}


Packages "simply using these libs" then would have to
BuildRequires: *-devel
=> They would receive those libs the package contains (normally only the
dynamic ones)


Packages "intentionally linking static" then would have to
BuildRequires: *-static
=> They would receive the ability to link statically.

Ralf

[Patrice Dumas]

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

[Ralf Corsepius]

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

[Patrice Dumas]

On Fri, Apr 20, 2007 at 01:06:51PM +0200, Ralf Corsepius wrote:
>  
>  The guidelines intention is to recommend "foo-static". 
Ok, so what about rpmlint warnings? Ignore them or bugzilla rpmlint?

>  If I was to decide, I would reject any static library unless a
> pressing
>  need of requiring a static lib can be demonstrated (!). 
There was a very long thread about that issue and I'd like not to repeat
it all over again. In summary, there are cases, like numerical models 
where all the reason that are for dynamic libraries don't make sense (use 
new version, security, dlopening, name resolution...) while compiling
statically helps being able to move programs to other hosts/linux
distros/ and so on. The other solution advocated instead of static 
linking (distributing shared libs along with the program and doing a
wrapper that setes things up) is much less practical.

Another reason may be the efficiency, as as demonstrated by Enrico 
numbers on tiny daemons, linking statically may lead to much more
efficient executables.

>  *-static is supposed to be what you seem to prefer to call
> "*-static-devel".
>  
>  The difference is just the name. 
I don't care about one or the other name, but rpmlint does.

>  >  (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. 
Not at all. I have specific needs.

--
Pat

[Ralf Corsepius]

On Fri, 2007-04-20 at 13:13 +0200, Patrice Dumas wrote:
>  On Fri, Apr 20, 2007 at 01:06:51PM +0200, Ralf Corsepius wrote:
>  > 
>  > The guidelines intention is to recommend "foo-static".
>  
>  Ok, so what about rpmlint warnings? Ignore them or bugzilla rpmlint? 
bugzilla it
against rpmlint, if you like to.

I don't know where this rpmlint warning stems from.

>  > If I was to decide, I would reject any static library unless a
> pressing
>  > need of requiring a static lib can be demonstrated (!).
>  
>  There was a very long thread about that issue and I'd like not to repeat
>  it all over again. In summary, there are cases, like numerical models 
>  where all the reason that are for dynamic libraries don't make sense (use 
>  new version, security, dlopening, name resolution...) while compiling
>  statically helps being able to move programs to other hosts/linux
>  distros/ and so on. The other solution advocated instead of static 
>  linking (distributing shared libs along with the program and doing a
>  wrapper that setes things up) is much less practical.
>  
>  Another reason may be the efficiency, as as demonstrated by Enrico 
>  numbers on tiny daemons, linking statically may lead to much more
>  efficient executables. 
What some people call efficiency, I call rending a distro
unmaintainable
and pimping "Linux" - To me, it's not much different from pimping a car
by installing an oxygen bottle to "make it faster".

>  
>  > >  (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.
>  
>  Not at all. I have specific needs. 
Well, your needs, i.e. "cross-distro binaries", are far from being
exotic. Many people before you went into trap you still seem to be
trapped into, before you, so be it :-)

Ralf

[Patrice Dumas]

On Fri, Apr 20, 2007 at 01:27:18PM +0200, Ralf Corsepius wrote:
>  bugzilla it against rpmlint, if you like to. 
Ok, that's what I'll do.

>  > Another reason may be the efficiency, as as demonstrated by
> Enrico 
>  > numbers on tiny daemons, linking statically may lead to much more
>  > efficient executables.
>  What some people call efficiency, I call rending a distro unmaintainable
>  and pimping "Linux" - To me, it's not much different from pimping a car
>  by installing an oxygen bottle to "make it faster". 
It may not be at the distro level. But I think that we shouldn't prevent
users to link statically their apps when it makes them faster.

>  Well, your needs, i.e. "cross-distro binaries", are far
> from being
>  exotic. Many people before you went into trap you still seem to be
>  trapped into, before you, so be it :-) 
I really don't understand what trap you are speaking about. I statically 
commpile a model on a computer then copy it over to other computers
(which may have different shared libraries or even not the libraries at
all) and run it (with different parameters of course) using a simple 
script to drive all the runs. What problem is there with that?

--
Pat

[Axel Thimm]

On Fri, Apr 20, 2007 at 01:13:41PM +0200, Patrice Dumas wrote:
>  On Fri, Apr 20, 2007 at 01:06:51PM +0200, Ralf Corsepius wrote:
>  > 
>  > The guidelines intention is to recommend "foo-static".
>  
>  Ok, so what about rpmlint warnings? Ignore them or bugzilla rpmlint? 
IIRC Ville wanted to speak with upstream to allow *.a in
*-static. Maybe he'll comment on what rpmlint currently does and
whether upstream perhaps rejected this, or perhaps whether my memory
is segfaulting. :)

>  > *-static is supposed to be what you seem to prefer to call
> "*-static-devel".
>  > 
>  > The difference is just the name.
>  
>  I don't care about one or the other name, but rpmlint does. 
What does rpmlint say? I think the idea was to have all, but static
libs in *-devel and *.a in *-static.

>  > >  (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.
>  
>  Not at all. I have specific needs. 
I think Ralf means that you are abusing Linux by computing numerical
models and doing serious number crunching. Go play a game ;)

(P.S. there is a smiley, but nevertheless: the above is a joke!)
-- 
Axel.Thimm at ATrpms.net

[Ralf Corsepius]

On Fri, 2007-04-20 at 13:33 +0200, Axel Thimm wrote:
>  On Fri, Apr 20, 2007 at 01:13:41PM +0200, Patrice Dumas wrote:
>  > > >  (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.
>  > 
>  > Not at all. I have specific needs.
>  
>  I think Ralf means that you are abusing Linux by computing numerical
>  models and doing serious number crunching. Go play a game ;)
>
>  (P.S. there is a smiley, but nevertheless: the above is a joke!) 
Of cause not .. I guess, I know what Pat's "special needs" are:
Cross-distro packaging:

- Sharing binaries across different distros, e.g. running Fedora built
apps on SuSE, Debian, Ubuntu and older RH based distros.

- Storing binaries for long-term to be able to reproduce results long
time after the distro they had been built on has been EOL'ed

- Reproducibility of results by eliminating the impact of multilibs, tls
etc.


He tries to achieve this by statically linking apps. This works for some
very simple apps (Pure numeric apps often qualify as such - Complex
mathematical algorithms but very simple wrt. system resources), but
doesn't work in general.

The g77/gfortran issue he reported in recent days probably are related
to this ;)

Ralf

[Patrice Dumas]

On Fri, Apr 20, 2007 at 01:42:59PM +0200, Ralf Corsepius wrote:
>  
>  Of cause not .. I guess, I know what Pat's "special needs" are:
>  Cross-distro packaging:
>  
>  - Sharing binaries across different distros, e.g. running Fedora built
>  apps on SuSE, Debian, Ubuntu and older RH based distros. 
Exactly. Statically linked libc requires a recent enough kernel, this
is what is currently limiting the portability of the executables I
generate.

>  - Storing binaries for long-term to be able to reproduce results
> long
>  time after the distro they had been built on has been EOL'ed 
In fact this doesn't work very well if I remember what was said in the
long thread I referred to.

>  - Reproducibility of results by eliminating the impact of multilibs,
> tls
>  etc. 
That is not one of my needs, but some scientists need that. I am not 
convinced that statically linking is a definite solution, but it may
help.
 
>  He tries to achieve this by statically linking apps. This works for
> some
>  very simple apps (Pure numeric apps often qualify as such - Complex
>  mathematical algorithms but very simple wrt. system resources), but
>  doesn't work in general. 
I agree with you that it doesn't work in general, but it works well for
me and I believe my case is very common within scientists: 
* use only mathematical libs
* have heterogeneous linuxes (both in time and in distros)
* want to run on all the computers in the lab
 
>  The g77/gfortran issue he reported in recent days probably are
> related
>  to this ;) 
Not exactly, but indeed statically compiling allows to compile with a
compiler and run on a platform where it isn't supported. g77 ICE on
some of my codes, so I cannot recompile on some distros, but still can
run gfortan compiled codes on those distros. Static linking is not 
always needed, but in practice it is, for example when libgfortran isn't
available.

--
Pat

[Ville Skyttä]

On Friday 20 April 2007, Axel Thimm wrote:
>  On Fri, Apr 20, 2007 at 01:13:41PM +0200, Patrice Dumas wrote:
>  > On Fri, Apr 20, 2007 at 01:06:51PM +0200, Ralf Corsepius wrote:
>  > > The guidelines intention is to recommend "foo-static".
>  >
>  > Ok, so what about rpmlint warnings? Ignore them or bugzilla rpmlint?
>
>  IIRC Ville wanted to speak with upstream to allow *.a in
>  *-static. Maybe he'll comment on what rpmlint currently does and
>  whether upstream perhaps rejected this, or perhaps whether my memory
>  is segfaulting. :) 
rpmlint 0.80 treats *-static as devel packages, earlier versions don't.