Hello folks,
I would like to know if there are any efforts to make both 32- and 64-bit versions of the same package "live" together in a system. I've been finding some packages that unfortunately break when you install both versions from the RPM (one example is Perl). Basically, what usually happens is:
- The executable files for both 32- and 64-bit versions have the same names (e.g., "perl", "python")
- The libraries for both versions are installed under /usr/lib
- Some other arch-dependent (therefore, bitness-dependent) files are installed at the same place for both versions
Those 3 situations make the last installed version to override things from the previous one.
So, do you intend to solve this problem in future versions of Fedora?
Thanks in advance,
Sérgio Durigan Júnior wrote:
Hello folks,
I would like to know if there are any efforts to make both 32- and 64-bit versions of the same package "live" together in a system.
32/64 bit versions of any/all packages? No.
But if the pkg's in question satisfy fedora's notion/definition of multilib (which is complicated in itself), yes.
Clear as mud? :)
-- Rex
Hi Rex,
On Thu, 2008-04-17 at 12:41 -0500, Rex Dieter wrote:
Sérgio Durigan Júnior wrote:
Hello folks,
I would like to know if there are any efforts to make both 32- and 64-bit versions of the same package "live" together in a system.
32/64 bit versions of any/all packages? No.
But if the pkg's in question satisfy fedora's notion/definition of multilib (which is complicated in itself), yes.
Well, what happens is that in some archs (specifically PowerPC in our case) it's very common to have a biarch environment (i.e., 64-bit kernel and mixed 32/64-bit userspace), so it's not a strange thing to have both versions of some software installed in the system. I've used Perl as an example, but I can cite a lot more packages that may need to be installed correctly in a biarch environment (Python, PHP, Ruby, Apache). That's the rationale behind my question :-).
BTW, can you please tell me where can I find the multilib definition? I've been reading http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks , but I don't know if it's official.
Thanks,
Sérgio Durigan Júnior wrote:
Well, what happens is that in some archs (specifically PowerPC in our case) it's very common to have a biarch environment (i.e., 64-bit kernel and mixed 32/64-bit userspace), so it's not a strange thing to have both versions of some software installed in the system.
Right. If there are 32/64 packages available, and they don't properly install/run, then that's generally considered a bug (that should be fixed).
-- Rex
On Thu, 2008-04-17 at 13:27 -0500, Rex Dieter wrote:
Sérgio Durigan Júnior wrote:
Well, what happens is that in some archs (specifically PowerPC in our case) it's very common to have a biarch environment (i.e., 64-bit kernel and mixed 32/64-bit userspace), so it's not a strange thing to have both versions of some software installed in the system.
Right. If there are 32/64 packages available, and they don't properly install/run, then that's generally considered a bug (that should be fixed).
Here is one:
# rpm -q --qf "%{name}.%{arch}\n" -f /lib/libgcc_s.so.1 libgcc.i386
# rpm -q --qf "%{name}.%{arch}\n" -f \ /usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so gcc.x86_64
# ls -l /usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so /usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so -> /lib/libgcc_s.so.1
i.e. an x86_64 package depending on an i386 package.
Now try to install /lib/libgcc_s.so.1 in an x86_64 mock chroot.
I am trying to package a package which needs to build and run some bits "-m32 compiled on x86_64". Works in a normal (multilib'ed x86_64) environment, but I haven't managed to get this working in mock.
Ralf
On Fri, 2008-04-18 at 05:19 +0200, Ralf Corsepius wrote:
On Thu, 2008-04-17 at 13:27 -0500, Rex Dieter wrote:
Sérgio Durigan Júnior wrote:
Well, what happens is that in some archs (specifically PowerPC in our case) it's very common to have a biarch environment (i.e., 64-bit kernel and mixed 32/64-bit userspace), so it's not a strange thing to have both versions of some software installed in the system.
Right. If there are 32/64 packages available, and they don't properly install/run, then that's generally considered a bug (that should be fixed).
Here is one:
# rpm -q --qf "%{name}.%{arch}\n" -f /lib/libgcc_s.so.1 libgcc.i386
# rpm -q --qf "%{name}.%{arch}\n" -f \ /usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so gcc.x86_64
# ls -l /usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so /usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so -> /lib/libgcc_s.so.1
i.e. an x86_64 package depending on an i386 package.
Now try to install /lib/libgcc_s.so.1 in an x86_64 mock chroot.
I am trying to package a package which needs to build and run some bits "-m32 compiled on x86_64". Works in a normal (multilib'ed x86_64) environment, but I haven't managed to get this working in mock.
try using yum 3.2.14 from rawhide with mock and remove the silly exclude that's in mock currently for x86_64 builds.
I know mdomsch and jkeating have tested it and had good success with multilib_policy=best
-sv
On Thu, 2008-04-17 at 23:33 -0400, seth vidal wrote:
On Fri, 2008-04-18 at 05:19 +0200, Ralf Corsepius wrote:
On Thu, 2008-04-17 at 13:27 -0500, Rex Dieter wrote:
Sérgio Durigan Júnior wrote:
Well, what happens is that in some archs (specifically PowerPC in our case) it's very common to have a biarch environment (i.e., 64-bit kernel and mixed 32/64-bit userspace), so it's not a strange thing to have both versions of some software installed in the system.
Right. If there are 32/64 packages available, and they don't properly install/run, then that's generally considered a bug (that should be fixed).
Here is one:
# rpm -q --qf "%{name}.%{arch}\n" -f /lib/libgcc_s.so.1 libgcc.i386
# rpm -q --qf "%{name}.%{arch}\n" -f \ /usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so gcc.x86_64
# ls -l /usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so /usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so -> /lib/libgcc_s.so.1
i.e. an x86_64 package depending on an i386 package.
Now try to install /lib/libgcc_s.so.1 in an x86_64 mock chroot.
I am trying to package a package which needs to build and run some bits "-m32 compiled on x86_64". Works in a normal (multilib'ed x86_64) environment, but I haven't managed to get this working in mock.
try using yum 3.2.14 from rawhide with mock and remove the silly exclude that's in mock currently for x86_64 builds.
OK, this will likely resolve the "mock" part of this issue (yet untested), but leaves other parts unclear:
Which rpm "arch" and which package does the /usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so -> /lib/libgcc_s.so.1 symlink belong to?
ATM, it is part of gcc.x86_86 and is a dangling symlink in "pure basearch" installs.
Should it (or even the whole m32 subdir) be part of an *.i386 package?
Or, conversely should /lib/libgcc_s.so.1 (clearly i386'ed) be part of a "multilib'ed" gcc.x86_64 package or libgcc.x86_64 package?
I don't know.
Ralf
packaging@lists.fedoraproject.org
-
Ralf Corsepius -
Rex Dieter -
Seth Vidal -
Sérgio Durigan Júnior