I do think it makes sense for yum to install both i386 and x86_64 variants of a package, if both are available, unless specified otherwise. What I don't think makes sense, though, is having /so/ many i386 packages available in the x86_64 tree, and thus also in the installation media.
Having 32-bit libraries makes sense, for the purpose of running legacy closed-source applications. Having i386 -devel packages... does not. What's the point, without a 32-bit compiler to go along?
And then there are the i386 applications: firefox, gaim, etc. These get installed by default (there's no way I can see to exclude i386 packages short of using kickstart). Removing them should be straightforward, right? Just yum --remove glibc.i686. But it's not that simple:
1. Often times, removing a 32-bit package also removes the files shared with the 64-bit sibling. 2. With the default FC6 install, I get a circular dependency when trying to remove glibc.i686. It never displays the final list of affected packages.
Would it be possible, for FC7, to limit the 32-bit packages included in -core to only the 32-bit libraries? Anything that installs to /usr/bin should be excluded. Maybe include a core-i386 repository that is by default disabled, for users who need 32-bit apps.
On Wednesday 25 October 2006 22:49, Michel Salim wrote:
Having 32-bit libraries makes sense, for the purpose of running legacy closed-source applications. Having i386 -devel packages... does not. What's the point, without a 32-bit compiler to go along?
The point is to be able to develop 32bit applications. 64bit gcc can create 32 bit binaries. -m32.
And then there are the i386 applications: firefox, gaim, etc. These get installed by default (there's no way I can see to exclude i386 packages short of using kickstart). Removing them should be straightforward, right? Just yum --remove glibc.i686. But it's not that simple:
These are showing up because they have a -devel subpackage, and the -devel subpackage is what we key off of to make it multilib. -devel requires its arch specific library (usually main) package.
As far as removing, yum remove *.i?86
Works for me every time. The only shared files that may get removed are documents (bug that needs to be fixed but not critical)
- Often times, removing a 32-bit package also removes the files
shared with the 64-bit sibling. 2. With the default FC6 install, I get a circular dependency when trying to remove glibc.i686. It never displays the final list of affected packages.
Again, try: yum remove *.i?86
On 10/25/06, Jesse Keating jkeating@redhat.com wrote:
And then there are the i386 applications: firefox, gaim, etc. These get installed by default (there's no way I can see to exclude i386 packages short of using kickstart). Removing them should be straightforward, right? Just yum --remove glibc.i686. But it's not that simple:
These are showing up because they have a -devel subpackage, and the -devel subpackage is what we key off of to make it multilib. -devel requires its arch specific library (usually main) package.
As far as removing, yum remove *.i?86
Works for me every time. The only shared files that may get removed are documents (bug that needs to be fixed but not critical)
Does not work for gaim at least: rpm -e gaim.i386 rpm -V gaim
shows a lot of missing files under /usr/share
Jesse Keating wrote :
As far as removing, yum remove *.i?86
Works for me every time. The only shared files that may get removed are documents (bug that needs to be fixed but not critical)
Nope. Translations also get removed. Docs gone... bad. Translations gone... _very_ bad :-(
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140055
Matthias
"JK" == Jesse Keating jkeating@redhat.com writes:
JK> Works for me every time. The only shared files that may get JK> removed are documents (bug that needs to be fixed but not JK> critical)
Why are files belonging to several packages ever removed, before the last package is gone?
/Benny
Benny Amorsen wrote:
"JK" == Jesse Keating jkeating@redhat.com writes:
JK> Works for me every time. The only shared files that may get JK> removed are documents (bug that needs to be fixed but not JK> critical)
Why are files belonging to several packages ever removed, before the last package is gone?
It shouldn't, and that's why it's a bug. (: http://bugzilla.redhat.com/140055 -- Rex
Rex Dieter wrote:
Benny Amorsen wrote:
> "JK" == Jesse Keating jkeating@redhat.com writes:
JK> Works for me every time. The only shared files that may get JK> removed are documents (bug that needs to be fixed but not JK> critical)
Why are files belonging to several packages ever removed, before the last package is gone?
It shouldn't, and that's why it's a bug. (: http://bugzilla.redhat.com/140055
Yes and a bug that needs fixing, its also here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209306
Where I've suggested a reasonable workaround, the problem is that currently rpm doesn't check if a file has multiple owners but just removes it if a package owning it gets removed, when this file is under one of the following dirs: _skip("/usr/share/zoneinfo"), _skip("/usr/share/locale"), _skip("/usr/share/i18n"), _skip("/usr/share/doc"), _skip("/usr/lib/locale"), _skip("/usr/src"), _skip("/lib/modules"),
This is known as the skipdirs patch, which was added because otherwise rpm's resident mem usage when doing rpm -e on a kernel when you have say 20+ kernels installed could become over 1Gig, which is a but of a problem on 512Mb or less machines.
The real fix for this would be to fix rpm's absurd mem usage in this scenarion but that isn't easily doable, thus I've suggested to reduce the skipdirs list to: _skip("/usr/share/zoneinfo"), _skip("/usr/share/i18n"), _skip("/usr/lib/locale"), _skip("/usr/src"), _skip("/lib/modules"),
Notice how the following 2 dirs where removed from the list: _skip("/usr/share/locale"), _skip("/usr/share/doc"),
Removing these 2 dirs is unlikely to trigger the Gig memusage scenario again, while at the same time reducing the impact of this problem to almost zero.
Unfortunately nobody sofar has responded to my suggestion to as an intermediate solution remove these 2 dirs from the skipdirs list, thus reducing the impact of this bug to almost 0.
Regards,
Hans
On 10/26/06, Hans de Goede j.w.r.degoede@hhs.nl wrote:
It shouldn't, and that's why it's a bug. (: http://bugzilla.redhat.com/140055
Yes and a bug that needs fixing, its also here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209306
Where I've suggested a reasonable workaround, the problem is that currently rpm doesn't check if a file has multiple owners but just removes it if a package owning it gets removed, when this file is under one of the following dirs: _skip("/usr/share/zoneinfo"), _skip("/usr/share/locale"), _skip("/usr/share/i18n"), _skip("/usr/share/doc"), _skip("/usr/lib/locale"), _skip("/usr/src"), _skip("/lib/modules"),
This is known as the skipdirs patch, which was added because otherwise rpm's resident mem usage when doing rpm -e on a kernel when you have say 20+ kernels installed could become over 1Gig, which is a but of a problem on 512Mb or less machines.
The real fix for this would be to fix rpm's absurd mem usage in this scenarion but that isn't easily doable, thus I've suggested to reduce the skipdirs list to: _skip("/usr/share/zoneinfo"), _skip("/usr/share/i18n"), _skip("/usr/lib/locale"), _skip("/usr/src"), _skip("/lib/modules"),
Notice how the following 2 dirs where removed from the list: _skip("/usr/share/locale"), _skip("/usr/share/doc"),
Removing these 2 dirs is unlikely to trigger the Gig memusage scenario again, while at the same time reducing the impact of this problem to almost zero.
Unfortunately nobody sofar has responded to my suggestion to as an intermediate solution remove these 2 dirs from the skipdirs list, thus reducing the impact of this bug to almost 0.
Who's the contact person in Red Hat when it comes to RPM right now, actually? The RPM limbo might be part of the problem here.
Regards,
On Thursday, 26 October 2006 at 15:32, Rex Dieter wrote:
Benny Amorsen wrote:
> "JK" == Jesse Keating jkeating@redhat.com writes:
JK> Works for me every time. The only shared files that may get JK> removed are documents (bug that needs to be fixed but not JK> critical)
Why are files belonging to several packages ever removed, before the last package is gone?
It shouldn't, and that's why it's a bug. (: http://bugzilla.redhat.com/140055
A bug that has been already fixed in upstream rpm-4.4.7, according to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140055#c14
Regards, R.
Hi Red Hat RPM people,
On Thu, 26 Oct 2006, Dominik 'Rathann' Mierzejewski wrote:
A bug that has been already fixed in upstream rpm-4.4.7, according to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140055#c14
this is just another good reason to solve my bug report opened up nearly one year ago which is expecting to upgrade RPM in Fedora Core to latest version 4.4.7, but exactly the Red Hat RPM people already mentioned above seem not to be interested in this (as far as I can see, they're hiding the whole thing behind pseudo-technical reasons) :-(
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174307
Greetings, Robert
On Wed, 2006-10-25 at 22:49 -0400, Michel Salim wrote:
I do think it makes sense for yum to install both i386 and x86_64 variants of a package, if both are available, unless specified otherwise. What I don't think makes sense, though, is having /so/ many i386 packages available in the x86_64 tree, and thus also in the installation media.
Having 32-bit libraries makes sense, for the purpose of running legacy closed-source applications. Having i386 -devel packages... does not. What's the point, without a 32-bit compiler to go along?
And then there are the i386 applications: firefox, gaim, etc. These get installed by default (there's no way I can see to exclude i386 packages short of using kickstart). Removing them should be straightforward, right? Just yum --remove glibc.i686. But it's not that simple:
- Often times, removing a 32-bit package also removes the files
shared with the 64-bit sibling. 2. With the default FC6 install, I get a circular dependency when trying to remove glibc.i686. It never displays the final list of affected packages.
Would it be possible, for FC7, to limit the 32-bit packages included in -core to only the 32-bit libraries? Anything that installs to /usr/bin should be excluded. Maybe include a core-i386 repository that is by default disabled, for users who need 32-bit apps.
-- Michel Salim http://salimma.livejournal.com/
Maybe this will be a good time to resurface this thread: http://www.redhat.com/archives/fedora-devel-list/2006-August/msg00709.html
- Gilboa
On 26-Oct-2006 12:02.37 (BST), Gilboa Davara wrote:
Maybe this will be a good time to resurface this thread: http://www.redhat.com/archives/fedora-devel-list/2006-August/msg00709.html
Doesn't strike me as a bad idea, but you should be able to manage this by performing an install from a customised repository (minus all of the i386 arch packages), running genhdlist and installing, then ensuring any installations are done along the lines of:
yum install <foo>.x86_64
A 'yum update' already does The Right Thing and only updates installed packages, so doesn't pull in any 32-bit packages that aren't already installed.
Maybe a "64-bit pure" flag for Anaconda would help make this easier?
On 10/26/06, Rob Andrews rob@choralone.org wrote:
On 26-Oct-2006 12:02.37 (BST), Gilboa Davara wrote:
Maybe this will be a good time to resurface this thread: http://www.redhat.com/archives/fedora-devel-list/2006-August/msg00709.html
Doesn't strike me as a bad idea, but you should be able to manage this by performing an install from a customised repository (minus all of the i386 arch packages), running genhdlist and installing, then ensuring any installations are done along the lines of:
yum install <foo>.x86_64
A 'yum update' already does The Right Thing and only updates installed packages, so doesn't pull in any 32-bit packages that aren't already installed.
Maybe a "64-bit pure" flag for Anaconda would help make this easier?
Perhaps call it "native binaries only" just in case there are more multilib architectures in Fedora's future.
On Thu, 2006-10-26 at 17:47 -0400, Michel Salim wrote:
On 10/26/06, Rob Andrews rob@choralone.org wrote:
On 26-Oct-2006 12:02.37 (BST), Gilboa Davara wrote:
Maybe this will be a good time to resurface this thread: http://www.redhat.com/archives/fedora-devel-list/2006-August/msg00709.html
Doesn't strike me as a bad idea, but you should be able to manage this by performing an install from a customised repository (minus all of the i386 arch packages), running genhdlist and installing, then ensuring any installations are done along the lines of:
yum install <foo>.x86_64
A 'yum update' already does The Right Thing and only updates installed packages, so doesn't pull in any 32-bit packages that aren't already installed.
Maybe a "64-bit pure" flag for Anaconda would help make this easier?
Perhaps call it "native binaries only" just in case there are more multilib architectures in Fedora's future.
The easiest solution will be to give the user an option to add yum exclude flags during the installation.
- Gibloa