10:30 a.m.
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
10:36 a.m.
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
10:50 a.m.
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
10:53 a.m.
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?
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
11 a.m.
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
11:03 a.m.
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
7:41 a.m.
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
8:57 a.m.
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.
--
Axel.Thimm at ATrpms.net
10:58 a.m.
>>>> "AT" == Axel Thimm
<Axel.Thimm(a)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<
1:46 p.m.
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.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
2:31 p.m.
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
5:49 a.m.
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
6:09 a.m.
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
6:14 a.m.
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
5602
days inactive
5606
days old
packaging@lists.fedoraproject.org
13 comments
9 participants
participants (9)
-
Axel Thimm -
Jason L Tibbitts III -
Jesse Keating -
Karsten Hopp -
Mamoru Tasaka -
Patrice Dumas -
Ralf Corsepius -
Till Maas -
Tom Callaway