i386 junk on x86_64 default install

[Michel Salim]

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.

-- 
Michel Salim
http://salimma.livejournal.com/

[Jesse Keating]

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)

>  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. 
Again, try: yum remove \*.i?86

-- 
Jesse Keating
Release Engineer: Fedora

[Michel Salim]

On 10/25/06, Jesse Keating <jkeating(a)redhat.com&gt; 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

-- 
Michel Salim
http://www.cs.indiana.edu/~msalim
http://the-dubois-papers.blogspot.com/

[Matthias Saou]

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

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 6 (Rawhide) - Linux kernel 2.6.18-1.2798.fc6
Load : 0.00 0.01 0.00

[Benny Amorsen]

> >>>> "JK" == Jesse Keating
> <jkeating(a)redhat.com&gt; 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

[Rex Dieter]

Benny Amorsen wrote:

> >>>>> "JK" == Jesse Keating
> <jkeating(a)redhat.com&gt; 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

[Hans de Goede]

Rex Dieter wrote:
>  Benny Amorsen wrote:
>  
> >>>>>> "JK" == Jesse Keating <jkeating(a)redhat.com&gt;
> 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

[Michel Salim]

On 10/26/06, Hans de Goede <j.w.r.degoede(a)hhs.nl&gt; 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,

-- 
Michel Salim
http://www.cs.indiana.edu/~msalim

[Jesse Keating]

On Thursday 26 October 2006 12:28, Michel Salim wrote:
>  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. 
Paul Nasrat.

-- 
Jesse Keating
Release Engineer: Fedora

[Dominik 'Rathann' Mierzejewski]

On Thursday, 26 October 2006 at 15:32, Rex Dieter wrote:
>  Benny Amorsen wrote:
>  
>  >>>>>> "JK" == Jesse Keating <jkeating(a)redhat.com&gt;
> 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.

-- 
Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski
MPlayer developer         http://rpm.greysector.net/mplayer/
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"

[Robert Scheck]

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

[Gilboa Davara]

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:
>  
>  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.
>  
>  -- 
>  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

[Rob Andrews]

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?

-- 
rob andrews                       :: pgp 0x01e00563 :: rob(a)choralone.org

[Michel Salim]

On 10/26/06, Rob Andrews <rob(a)choralone.org&gt; 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.


-- 
Michel Salim
http://www.cs.indiana.edu/~msalim

[Gilboa Davara]

On Thu, 2006-10-26 at 17:47 -0400, Michel Salim wrote:
>  On 10/26/06, Rob Andrews <rob(a)choralone.org&gt; 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