Bug 127738 - Should use %{_libdir} instead of /usr/lib
Summary: Should use %{_libdir} instead of /usr/lib
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: rhnlib (Show other bugs)
(Show other bugs)
Version: 2
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Mihai Ibanescu
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-07-13 05:35 UTC by Aleksey Nogin
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-07-13 12:37:04 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Aleksey Nogin 2004-07-13 05:35:26 UTC
On x86_64 platform, rhnlib installs all the files into the
/usr/lib/python2.3/site-packages/rhn/ directory. It should probably be
using /usr/lib64/python2.3/site-packages/rhn/ (note the "64").

Comment 1 Mihai Ibanescu 2004-07-13 12:37:04 UTC
Sort of.
rhnlib is a noarch package, because it is python code that is portable
on all arches.
It would be a pain to recompile all noarch packages on 64-bit arches
just to drop them in /usr/lib64 instead of /usr/lib. We chose to keep
looking for packages in /usr/lib even on 64-bit platforms, so that we
can reuse the noarch packages.
Needless to say, python does not play very nicely with multilib.
Should FHS have chosen /usr64 as a place to drop 64-bit packages, we
could have just changed sys.exec_prefix. Unfortunately, python slaps
lib at the end of both sys.prefix and sys.exec_prefix, so it needs
patching in order to make it obey FHS.
Please feel free to reopen the bug if you think this is incorrect or
rhnlib does not work on 64-bit arches (although I know it does).


Note You need to log in before you can comment on or make changes to this bug.