I've run a x86_64 mass rebuild of all our Fedora packages and found several noarch packages which erronously use {_libdir} or {_lib} in their spec files. rpmdiff shows this output:
./firstaidkit-0.2.2-5.fc11.noarch.rpm removed /usr/lib/firstaidkit removed /usr/lib/firstaidkit/plugins added /usr/lib64/firstaidkit added /usr/lib64/firstaidkit/plugins
As noarch packages can be built on any machine/architecture in koji, we'd end up with lib64 directories on 32bit archs
Here is the list of offending packages I've found:
Package Owner ------------------------ ntfs-config laxathom firstaidkit msivak terminus-font ndim gdeskcal pfj libopensync-plugin-synce awjb cohoba tjikkun gnome-schedule farnold common-lisp-controller green gcstar tian revisor-cli jsteffan jruby konradm
Can we make it a policy to not use _libdir or _lib in noarch packages, please ?
Karsten
On Thu, 2008-12-18 at 17:30 +0100, Karsten Hopp wrote:
I've run a x86_64 mass rebuild of all our Fedora packages and found several noarch packages which erronously use {_libdir} or {_lib} in their spec files. rpmdiff shows this output:
./firstaidkit-0.2.2-5.fc11.noarch.rpm removed /usr/lib/firstaidkit removed /usr/lib/firstaidkit/plugins added /usr/lib64/firstaidkit added /usr/lib64/firstaidkit/plugins
As noarch packages can be built on any machine/architecture in koji, we'd end up with lib64 directories on 32bit archs
Here is the list of offending packages I've found:
Package Owner
ntfs-config laxathom firstaidkit msivak terminus-font ndim gdeskcal pfj libopensync-plugin-synce awjb cohoba tjikkun gnome-schedule farnold common-lisp-controller green gcstar tian revisor-cli jsteffan jruby konradm
Can we make it a policy to not use _libdir or _lib in noarch packages, please ?
Wouldn't it be better to let rpm set _libdir/_lib to match noarch package requirements?
Ralf
On Thu, 2008-12-18 at 17:36 +0100, Ralf Corsepius wrote:
Wouldn't it be better to let rpm set _libdir/_lib to match noarch package requirements?
What should it set it to? It has no knowledge of where the noarch rpm package will eventually be installed. Should we assume that /usr/lib is always correct (how Debian of me to even suggest this)?
~spot
On Thu, 2008-12-18 at 11:50 -0500, Tom "spot" Callaway wrote:
On Thu, 2008-12-18 at 17:36 +0100, Ralf Corsepius wrote:
Wouldn't it be better to let rpm set _libdir/_lib to match noarch package requirements?
What should it set it to? It has no knowledge of where the noarch rpm package will eventually be installed. Should we assume that /usr/lib is always correct (how Debian of me to even suggest this)?
~spot
Also, how does one get this right in the age of noarch subpackages to arch specific packages?
On Thu, 2008-12-18 at 08:53 -0800, Jesse Keating wrote:
On Thu, 2008-12-18 at 11:50 -0500, Tom "spot" Callaway wrote:
On Thu, 2008-12-18 at 17:36 +0100, Ralf Corsepius wrote:
Wouldn't it be better to let rpm set _libdir/_lib to match noarch package requirements?
What should it set it to? It has no knowledge of where the noarch rpm package will eventually be installed. Should we assume that /usr/lib is always correct (how Debian of me to even suggest this)?
~spot
Also, how does one get this right in the age of noarch subpackages to arch specific packages?
By properly parsing and preserving contexts in rpmbuild?
Admitted, "proper", "parsing" and "contexts" don't go well along with rpm.
Ralf
On Thu, 2008-12-18 at 11:50 -0500, Tom "spot" Callaway wrote:
On Thu, 2008-12-18 at 17:36 +0100, Ralf Corsepius wrote:
Wouldn't it be better to let rpm set _libdir/_lib to match noarch package requirements?
What should it set it to? It has no knowledge of where the noarch rpm package will eventually be installed.
It has. In case of noarch _lib always is the "default", which normally is lib.
Should we assume that /usr/lib is always correct (how Debian of me to even suggest this)?
In case of noarch, yes.
Because an arch'aware (e.g. lib vs. lib64) _lib/_libdir qualifies a package as "arch'ed"
Ralf
On Thu, Dec 18, 2008 at 11:50:37AM -0500, Tom spot Callaway wrote:
On Thu, 2008-12-18 at 17:36 +0100, Ralf Corsepius wrote:
Wouldn't it be better to let rpm set _libdir/_lib to match noarch package requirements?
What should it set it to? It has no knowledge of where the noarch rpm package will eventually be installed. Should we assume that /usr/lib is always correct (how Debian of me to even suggest this)?
Isn't the norach equivalent of _libdir _datadir? Or phrased in another way: Shouldn't a noach package avoid both lib and lib64? I think we even have rules already set for this.
I don't quite agree that rpm should start changing _libdir to point to _datadir, but the packagers should probably patch up the packages to use _datadir instead of _libdir if the package is indeed noarch.
"AT" == Axel Thimm Axel.Thimm@ATrpms.net writes:
AT> Isn't the norach equivalent of _libdir _datadir? Or phrased in AT> another way: Shouldn't a noach package avoid both lib and lib64? I AT> think we even have rules already set for this.
Well, sort of, but it doesn't always work out that way in practise. Witness Perl and Python, for example, which should both put arch-independent modules in datadir but put them in /usr/lib instead. Which leads to the fun situation where you can get it wrong and have the package work on i386 but fail to build on x86_64.
Still, those languages have their own macros which give you the right thing. We don't have anything in general, and I agree that we shouldn't really encourage it. When really necessary, I've always recommended just using %{_prefix}/lib to make it really obvious.
- J<
On Sat, 2008-12-20 at 16:57 +0200, Axel Thimm wrote:
Isn't the norach equivalent of _libdir _datadir? Or phrased in another way: Shouldn't a noach package avoid both lib and lib64? I think we even have rules already set for this.
I don't quite agree that rpm should start changing _libdir to point to _datadir, but the packagers should probably patch up the packages to use _datadir instead of _libdir if the package is indeed noarch.
What about noarch python modules which live in /usr/lib/python(ver)/site-packages/ ? Perl in /usr/lib/perl(ver)/ ? So on, and so forth.
On Sat, Dec 20, 2008 at 11:46:44AM -0800, Jesse Keating wrote:
What about noarch python modules which live in /usr/lib/python(ver)/site-packages/ ? Perl in /usr/lib/perl(ver)/ ? So on, and so forth.
Should be the only 2 exceptions. In my opinion these are wrong but long established, and maybe not worth changing, or it is to be seen with their maintainers.
There is a rpmlint warning when there is only noarch content in %_libdir, I think this is right.
-- Pat
On Saturday 20 December 2008 21:31:49 Patrice Dumas wrote:
On Sat, Dec 20, 2008 at 11:46:44AM -0800, Jesse Keating wrote:
What about noarch python modules which live in /usr/lib/python(ver)/site-packages/ ? Perl in /usr/lib/perl(ver)/ ? So on, and so forth.
Should be the only 2 exceptions. In my opinion these are wrong but long established, and maybe not worth changing, or it is to be seen with their maintainers.
There is a rpmlint warning when there is only noarch content in %_libdir, I think this is right.
Here is another exception you might consider:
$ rpm -qf /usr/lib/rpm/redhat/find-requires redhat-rpm-config-9.0.3-3.fc10.noarch
Regards, Till
On Mon, Dec 22, 2008 at 12:49:05PM +0100, Till Maas wrote:
Here is another exception you might consider:
$ rpm -qf /usr/lib/rpm/redhat/find-requires redhat-rpm-config-9.0.3-3.fc10.noarch
This is not the same here. Here it is a mixed arch/noarch package. The redhat-rpm-config happens to be strictly noarch, but it isn't the case for rpm-build, for example rpmdeps is an ELF file.
That being said, this is unclear to me whether using /usr/lib is right or wrong for rpm. Maybe the scripts should be in _libexec, and the macros in _datadir.
-- Pat
Patrice Dumas wrote, at 12/21/2008 05:31 AM +9:00:
On Sat, Dec 20, 2008 at 11:46:44AM -0800, Jesse Keating wrote:
What about noarch python modules which live in /usr/lib/python(ver)/site-packages/ ? Perl in /usr/lib/perl(ver)/ ? So on, and so forth.
Should be the only 2 exceptions. In my opinion these are wrong but long established, and maybe not worth changing, or it is to be seen with their maintainers.
There is a rpmlint warning when there is only noarch content in %_libdir, I think this is right.
-- Pat
And Ruby always uses /usr/lib/ruby. Another example is /usr/lib/bonobo/servers (ref: bug 463054)
Mamoru
Ralf Corsepius schrieb:
On Thu, 2008-12-18 at 17:30 +0100, Karsten Hopp wrote:
I've run a x86_64 mass rebuild of all our Fedora packages and found several noarch packages which erronously use {_libdir} or {_lib} in their spec files. rpmdiff shows this output:
./firstaidkit-0.2.2-5.fc11.noarch.rpm removed /usr/lib/firstaidkit removed /usr/lib/firstaidkit/plugins added /usr/lib64/firstaidkit added /usr/lib64/firstaidkit/plugins
As noarch packages can be built on any machine/architecture in koji, we'd end up with lib64 directories on 32bit archs
Here is the list of offending packages I've found:
Package Owner
ntfs-config laxathom firstaidkit msivak terminus-font ndim gdeskcal pfj libopensync-plugin-synce awjb cohoba tjikkun gnome-schedule farnold common-lisp-controller green gcstar tian revisor-cli jsteffan jruby konradm
Can we make it a policy to not use _libdir or _lib in noarch packages, please ?
Wouldn't it be better to let rpm set _libdir/_lib to match noarch package requirements?
Ralf
I don't have any preferences on how we solve it, I'll leave that for FPC to decide. But I think it needs to be solved or we'll run out of luck and build one of those packages on 64bit anytime soon.
Karsten
packaging@lists.fedoraproject.org