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
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
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
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
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
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
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
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!)
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
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
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.
packaging@lists.fedoraproject.org
-
Axel Thimm -
Patrice Dumas -
Ralf Corsepius -
Ville Skyttä