4:21 p.m.
Hi,
I can't really understand whether the Playstation 3 running Fedora 8 supposed to be
ppc or ppc64.
The question arises because it seems that it is not possible to install both RPMs for ppc
and ppc64
for all application.
For instance: I cannot install alsa-lib-devel for both because they provide the same
documentation
files that conflict.
The same for gdb-ppc and gdb-ppc64. I have both RPMs installed, but gdb is in the same
path for
both: /usr/bin/gdb and only the last survives, the first is overwritten?
Am I wrong?
8:57 a.m.
On Sat, 23 Feb 2008 22:21:49 +0000
Andrea <mariofutire(a)googlemail.com> wrote:
Hi,
I can't really understand whether the Playstation 3 running Fedora 8
supposed to be ppc or ppc64.
The question arises because it seems that it is not possible to
install both RPMs for ppc and ppc64 for all application.
For instance: I cannot install alsa-lib-devel for both because they
provide the same documentation files that conflict.
The same for gdb-ppc and gdb-ppc64. I have both RPMs installed, but
gdb is in the same path for both: /usr/bin/gdb and only the last
survives, the first is overwritten?
Am I wrong?
You're supposed to use the "ppc" release of Fedora, booting the ppc64
kernel. The installer will take care to install the right mix of
packages for you.
(well, "right" may be a stretch, at least a working set.)
--
Jesse Keating RHCE (jkeating.livejournal.com)
Fedora Project (fedoraproject.org/wiki/JesseKeating)
GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub)
1:16 p.m.
Jesse Keating wrote:
On Sat, 23 Feb 2008 22:21:49 +0000
Andrea <mariofutire(a)googlemail.com> wrote:
You're supposed to use the "ppc" release of Fedora, booting the ppc64
kernel. The installer will take care to install the right mix of
packages for you.
(well, "right" may be a stretch, at least a working set.)
The installer has decided for me the following
1) I can run ppc and ppc64 apps because I have almost all libraries in both versions
2) I can only develop alsa-ppc64 apps. It has decided to install alsa-lib-devel.ppc64
I cannot install alsa-lib-devel.ppc because there is a conflict (they both provide the
same files:
i.e. the same documentation)
3) I can only debug ppc apps. Even if I have gdb-ppc and gdb-ppc64, I can only see the ppc
version
of gdb. Since they are both supposed to be in /usr/bin/gdb I guess the last installation
overwrites
the first.
I've tried manually extract gdb from the 2 RPMs and I can see that the one installed
as /usr/bin/gdb
comes from ppc (and it does not debug ppc64 apps).
4) many other applications are in the same situation. For instance I have firefox-ppc and
firefox-ppc64. Most of firefox is under /usr/lib and /usr/lib64 so it looks to me a waste
of space
since they both do the same.
The set is theoretically a "working set", but it does not make much sense.
I think I will try to remove all devel-ppc64 versions so that I can develop for ppc
without issues.
I don't think it is an easy problem to solve, unless one mirrors all system
directories.
At present only /usr/lib and /usr/lib64 can fully coexists.
Or one could choose at the beginning to install only ppc or ppc64.
Am I just talking nonsense?
8:38 a.m.
On Sun, 24 Feb 2008 19:16:55 +0000
Andrea <mariofutire(a)googlemail.com> wrote:
I don't think it is an easy problem to solve, unless one mirrors
all
system directories. At present only /usr/lib and /usr/lib64 can fully
coexists.
Or one could choose at the beginning to install only ppc or ppc64.
Am I just talking nonsense?
You can't just be ppc, as the ppc kernel won't boot on ppc64. You
shouldn't be all ppc64 either, because the ppc64 binaries tend to be
slower than their ppc counterparts. What you really need is a small
mix of both, but that makes developing one or the other somewhat
difficult. Welcome to the hell of multilib.
I suggest making use of mock to create chroots of pure archness to
develop with. Mock can give you a pure ppc chroot and a pure ppc64
chroot for which to develop in.
--
Jesse Keating RHCE (jkeating.livejournal.com)
Fedora Project (fedoraproject.org/wiki/JesseKeating)
GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub)
3:21 p.m.
Jesse Keating wrote:
On Sun, 24 Feb 2008 19:16:55 +0000
Andrea <mariofutire(a)googlemail.com> wrote:
You can't just be ppc, as the ppc kernel won't boot on ppc64. You
shouldn't be all ppc64 either, because the ppc64 binaries tend to be
slower than their ppc counterparts. What you really need is a small
mix of both, but that makes developing one or the other somewhat
difficult. Welcome to the hell of multilib.
Indeed!
I suggest making use of mock to create chroots of pure archness to
develop with. Mock can give you a pure ppc chroot and a pure ppc64
chroot for which to develop in.
To be honest, I am perfectly happy to live in a world of
kernel is ppc64
everything else is ppc
So my plan is:
1) remove all devel packages for ppc64 and replace (if missing) with ppc
2) remove all duplicate applications ppc/ppc64 keeping only ppc
3) keep all libraries on both versions so I can (just in case) still run everything
would that work?
You'll know it soon!
3:26 p.m.
On Mon, 2008-02-25 at 21:21 +0000, Andrea wrote:
Jesse Keating wrote:
> On Sun, 24 Feb 2008 19:16:55 +0000
> Andrea <mariofutire(a)googlemail.com> wrote:
>
> You can't just be ppc, as the ppc kernel won't boot on ppc64. You
> shouldn't be all ppc64 either, because the ppc64 binaries tend to be
> slower than their ppc counterparts. What you really need is a small
> mix of both, but that makes developing one or the other somewhat
> difficult. Welcome to the hell of multilib.
Indeed!
>
> I suggest making use of mock to create chroots of pure archness to
> develop with. Mock can give you a pure ppc chroot and a pure ppc64
> chroot for which to develop in.
>
To be honest, I am perfectly happy to live in a world of
kernel is ppc64
everything else is ppc
So my plan is:
1) remove all devel packages for ppc64 and replace (if missing) with ppc
2) remove all duplicate applications ppc/ppc64 keeping only ppc
3) keep all libraries on both versions so I can (just in case) still run everything
would that work?
iirc, there are a few userspace things where you really actually do want
the ppc64 version. I believe at least gdb and crash were on that list.
32-bit versions won't know what to do when analyzing 64-bit bits.
--
Jarod Wilson
jarod(a)wilsonet.com
3:38 p.m.
On Mon, 25 Feb 2008 16:26:12 -0500
Jarod Wilson <jarod(a)wilsonet.com> wrote:
On Mon, 2008-02-25 at 21:21 +0000, Andrea wrote:
> Jesse Keating wrote:
> > On Sun, 24 Feb 2008 19:16:55 +0000
> > Andrea <mariofutire(a)googlemail.com> wrote:
> >
> > You can't just be ppc, as the ppc kernel won't boot on ppc64. You
> > shouldn't be all ppc64 either, because the ppc64 binaries tend to be
> > slower than their ppc counterparts. What you really need is a small
> > mix of both, but that makes developing one or the other somewhat
> > difficult. Welcome to the hell of multilib.
>
> Indeed!
>
> >
> > I suggest making use of mock to create chroots of pure archness to
> > develop with. Mock can give you a pure ppc chroot and a pure ppc64
> > chroot for which to develop in.
> >
>
> To be honest, I am perfectly happy to live in a world of
>
> kernel is ppc64
> everything else is ppc
>
> So my plan is:
>
> 1) remove all devel packages for ppc64 and replace (if missing) with ppc
> 2) remove all duplicate applications ppc/ppc64 keeping only ppc
> 3) keep all libraries on both versions so I can (just in case) still run everything
>
> would that work?
iirc, there are a few userspace things where you really actually do want
the ppc64 version. I believe at least gdb and crash were on that list.
32-bit versions won't know what to do when analyzing 64-bit bits.
Yes.
josh
3:42 p.m.
Jarod Wilson wrote:
On Mon, 2008-02-25 at 21:21 +0000, Andrea wrote:
> Jesse Keating wrote:
iirc, there are a few userspace things where you really actually do want
the ppc64 version. I believe at least gdb and crash were on that list.
32-bit versions won't know what to do when analyzing 64-bit bits.
I agree, but it is not working anyway.
I would like to have gdb.32 and gdb.64 but I can only have one of them.
When they are both installed, gdb.64 disappears...
4:01 p.m.
On Mon, 2008-02-25 at 21:42 +0000, Andrea wrote:
Jarod Wilson wrote:
> On Mon, 2008-02-25 at 21:21 +0000, Andrea wrote:
>> Jesse Keating wrote:
> iirc, there are a few userspace things where you really actually do want
> the ppc64 version. I believe at least gdb and crash were on that list.
> 32-bit versions won't know what to do when analyzing 64-bit bits.
>
>
I agree, but it is not working anyway.
I would like to have gdb.32 and gdb.64 but I can only have one of them.
Why? gdb.ppc64 can debug both 32-bit and 64-bit stuff. Go with just the
64-bit one.
When they are both installed, gdb.64 disappears...
Remove the 32-bit one. Reinstall the 64-bit one, if need be. I'm a bit
fuzzy on the details of how that all works w/overlapping binaries...
--
Jarod Wilson
jarod(a)wilsonet.com
4:17 p.m.
Jarod Wilson wrote:
On Mon, 2008-02-25 at 21:42 +0000, Andrea wrote:
Remove the 32-bit one. Reinstall the 64-bit one, if need be. I'm a bit
fuzzy on the details of how that all works w/overlapping binaries...
Great!
You are right!
gdb.ppc64 works for both of them!
I've removed both of them and reinstalled only gdb.ppc64!
Still I think yum should have doe it for me.
Andrea
4:35 p.m.
On Mon, 25 Feb 2008 22:17:22 +0000
Andrea <mariofutire(a)googlemail.com> wrote:
Jarod Wilson wrote:
> On Mon, 2008-02-25 at 21:42 +0000, Andrea wrote:
>
> Remove the 32-bit one. Reinstall the 64-bit one, if need be. I'm a bit
> fuzzy on the details of how that all works w/overlapping binaries...
>
>
Great!
You are right!
gdb.ppc64 works for both of them!
I've removed both of them and reinstalled only gdb.ppc64!
Still I think yum should have doe it for me.
It's not really easy for yum to figure that out. What you want might
be different from what others want, etc. It also doesn't help that
x86_64 and ppc64 have almost exact opposite semantics as far as what
is considered the "good" arch. That being said, there is work on-going
in the yum area to improve the situation for multi-lib.
josh
4:42 p.m.
Josh Boyer wrote:
On Mon, 25 Feb 2008 22:17:22 +0000
Andrea <mariofutire(a)googlemail.com> wrote:
> Jarod Wilson wrote:
It's not really easy for yum to figure that out. What you want might
be different from what others want, etc. It also doesn't help that
x86_64 and ppc64 have almost exact opposite semantics as far as what
is considered the "good" arch. That being said, there is work on-going
in the yum area to improve the situation for multi-lib.
I understand all that. It looks a difficult task to me.
I am happy to be in charge to choose which of the 2 to install,
but:
"When yum tells me that both gdb.ppc and gdb.ppc64 are installed, it is not true.
I would call it a bug."
Only one of them is usable (maybe the last to have been installed, but I am not sure).
I am now trying to clean and remove duplicates, but it is not always easy.
It looks to me that yum thinks the ppc and ppc64 version of many packages are somehow
equivalent (in
the sense that they are both good to satisfy dependencies, if one of the is already
installed).
Andrea
8:29 p.m.
On Mon, 25 Feb 2008 22:42:28 +0000
Andrea <mariofutire(a)googlemail.com> wrote:
Josh Boyer wrote:
> On Mon, 25 Feb 2008 22:17:22 +0000
> Andrea <mariofutire(a)googlemail.com> wrote:
>
>> Jarod Wilson wrote:
>
> It's not really easy for yum to figure that out. What you want might
> be different from what others want, etc. It also doesn't help that
> x86_64 and ppc64 have almost exact opposite semantics as far as what
> is considered the "good" arch. That being said, there is work on-going
> in the yum area to improve the situation for multi-lib.
>
I understand all that. It looks a difficult task to me.
I am happy to be in charge to choose which of the 2 to install,
but:
"When yum tells me that both gdb.ppc and gdb.ppc64 are installed, it is not true.
I would call it a bug."
Only one of them is usable (maybe the last to have been installed, but I am not sure).
Yum can only report what the underlying package manager does for
installed applications. That's RPM. The problem is in RPM, not yum.
josh
5897
days inactive
5900
days old
12 comments
4 participants
participants (4)
-
Andrea -
Jarod Wilson -
Jesse Keating -
Josh Boyer