Hello there,
I've just received some feedback from 3 users with fc5 and fc6t3 x86_64.
All the three of them: yum is downloading both 32 bits and 64 bit versions of the same packages, hence during installation there are conflicts.
Is this a known issue ? is there a solution and in fc6 will it be corrected?
chitlesh
ons, 18 10 2006 kl. 12:13 +0200, skrev Chitlesh GOORAH:
Hello there,
I've just received some feedback from 3 users with fc5 and fc6t3 x86_64.
All the three of them: yum is downloading both 32 bits and 64 bit versions of the same packages, hence during installation there are conflicts.
Is this a known issue ? is there a solution and in fc6 will it be corrected?
chitlesh
Welcome to the absolute hell that is multilib
Please report the conflicts to they can be resolved.
- David Nielsen
Chitlesh GOORAH wrote:
Hello there,
I've just received some feedback from 3 users with fc5 and fc6t3 x86_64.
All the three of them: yum is downloading both 32 bits and 64 bit versions of the same packages, hence during installation there are conflicts.
Is this a known issue ? is there a solution and in fc6 will it be corrected?
chitlesh
They should do "yum install foo.x86_64" instead of just "yum install foo", also when they update they shouldn't do piecemeal updates.
Regards,
Hans
Hans de Goede wrote:
Chitlesh GOORAH wrote:
Hello there,
I've just received some feedback from 3 users with fc5 and fc6t3 x86_64.
All the three of them: yum is downloading both 32 bits and 64 bit versions of the same packages, hence during installation there are conflicts.
Is this a known issue ? is there a solution and in fc6 will it be corrected?
chitlesh
They should do "yum install foo.x86_64" instead of just "yum install foo", also when they update they shouldn't do piecemeal updates.
just add this to /etc/yum.conf
exclude=*.i386 *.i686 *.i586 *.athlon
On 10/19/06, Denis Leroy <> wrote:
They should do "yum install foo.x86_64" instead of just "yum install foo", also when they update they shouldn't do piecemeal updates.
how about the dependencies yum is fetching ?
just add this to /etc/yum.conf exclude=*.i386 *.i686 *.i586 *.athlon
Should this be included by default for x86_64 ? user joe won't figure it out like this.
chitlesh
On Wednesday 18 October 2006 19:28, Chitlesh GOORAH wrote:
Should this be included by default for x86_64 ? user joe won't figure it out like this.
Absolutely not. An end user's multilib capable machine + OS should install the multilib software by default. An end user shouldn't have to figure out how to add it after the fact. It should Just Work(tm) for the user. There should be no problem with the x86_64 and i386 packages being installed. If there are, like multilib file conflicts, we fix them.
On 10/19/06, Jesse Keating <xxxx> wrote:
Absolutely not. An end user's multilib capable machine + OS should install the multilib software by default. An end user shouldn't have to figure out how to add it after the fact. It should Just Work(tm) for the user. There should be no problem with the x86_64 and i386 packages being installed. If there are, like multilib file conflicts, we fix them.
can yum search for foo and if it finds foo-N-N.x86_64.rpm it downloads it. If not it will download the 32 bit version. However if it finds foo-N-N.x86_64.rpm it should not download the 32 bit version (to prevent conflict).
"It should Just Work(tm) for the user" well my 3 sources have the same problem, and yum update fails each time. It is not just working for the user.
chitlesh
On Thursday 19 October 2006 03:12, Chitlesh GOORAH wrote:
can yum search for foo and if it finds foo-N-N.x86_64.rpm it downloads it. If not it will download the 32 bit version. However if it finds foo-N-N.x86_64.rpm it should not download the 32 bit version (to prevent conflict).
There should BE no conflict between the i386 and the x86_64 package. If there is, it is a bug in the PACKAGE, not in the update tool.
"It should Just Work(tm) for the user" well my 3 sources have the same problem, and yum update fails each time. It is not just working for the user.
What were these conflicts? Where are the bugs? What release were they using?
Don't shoot the mailman because he delivered a correctly addressed package to your house, and it turned out to be a bomb. Shoot the person who made the package (:
Chitlesh GOORAH wrote:
On 10/19/06, Jesse Keating <xxxx> wrote:
Absolutely not. An end user's multilib capable machine + OS should install the multilib software by default. An end user shouldn't have to figure out how to add it after the fact. It should Just Work(tm) for the user. There should be no problem with the x86_64 and i386 packages being installed. If there are, like multilib file conflicts, we fix them.
can yum search for foo and if it finds foo-N-N.x86_64.rpm it downloads it. If not it will download the 32 bit version. However if it finds foo-N-N.x86_64.rpm it should not download the 32 bit version (to prevent conflict).
This is not how yum works, when you say "yum install XXX", then yum will try to install packages that provide XXX in any way, so for example you can say yum install /usr/bin/joe to install joe. When multiple packages's (including multiple archs) match XXX then they all get installed as yum doesn't know which one you want and installing all is better then installing a random one.
Now with that said there has been discussion in the past that in the same packages with multiple archs case, that yum should behave different, see the archives.
Regards,
Hans
Chitlesh GOORAH wrote:
On 10/19/06, Jesse Keating <xxxx> wrote:
Absolutely not. An end user's multilib capable machine + OS should install the multilib software by default. An end user shouldn't have to figure out how to add it after the fact. It should Just Work(tm) for the user. There should be no problem with the x86_64 and i386 packages being installed. If there are, like multilib file conflicts, we fix them.
can yum search for foo and if it finds foo-N-N.x86_64.rpm it downloads it. If not it will download the 32 bit version. However if it finds foo-N-N.x86_64.rpm it should not download the 32 bit version (to prevent conflict).
"It should Just Work(tm) for the user" well my 3 sources have the same problem, and yum update fails each time. It is not just working for the user.
Is the conflicting package nautilus ? If so, see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=205260
DaveT.
On Wed, Oct 18, 2006 at 11:00:37PM -0400, Jesse Keating wrote:
On Wednesday 18 October 2006 19:28, Chitlesh GOORAH wrote:
Should this be included by default for x86_64 ? user joe won't figure it out like this.
Absolutely not. An end user's multilib capable machine + OS should install the multilib software by default. An end user shouldn't have to figure out how to add it after the fact. It should Just Work(tm) for the user. There should be no problem with the x86_64 and i386 packages being installed. If there are, like multilib file conflicts, we fix them.
Is it true for Extras? I haven't seen anything like a push for multilib in extras, for example there is nothing in the guidelines, nor something reporting the conflicts. Did I miss something?
-- Pat
On Thursday 19 October 2006 04:27, Patrice Dumas wrote:
Is it true for Extras? I haven't seen anything like a push for multilib in extras, for example there is nothing in the guidelines, nor something reporting the conflicts. Did I miss something?
Extras is on its way to becoming multilib. There will be a LOT of conflicts to fix, just like there was in Core when we went multilib, and then FURTHER multilib.
On Thu, 19 Oct 2006 10:27:43 +0200, Patrice Dumas wrote:
On Wed, Oct 18, 2006 at 11:00:37PM -0400, Jesse Keating wrote:
On Wednesday 18 October 2006 19:28, Chitlesh GOORAH wrote:
Should this be included by default for x86_64 ? user joe won't figure it out like this.
Absolutely not. An end user's multilib capable machine + OS should install the multilib software by default. An end user shouldn't have to figure out how to add it after the fact. It should Just Work(tm) for the user. There should be no problem with the x86_64 and i386 packages being installed. If there are, like multilib file conflicts, we fix them.
Is it true for Extras? I haven't seen anything like a push for multilib in extras, for example there is nothing in the guidelines, nor something reporting the conflicts. Did I miss something?
We've talked about it a few weeks ago. Currently, only Wine i386 plus its dependencies are copied into the x86_64 repository. With every push of new packages, updates of packages in the dependency chain are recognised and are distributed to the multi-lib repositories automatically, too.
As soon as the FC-6 branch is available, we can switch a few bits for the next "development" tree of Extras and copy all *-devel packages and their dependencies, too. Additional work will be needed as conflicts are found and as we find packages we want to add to the white-list and black-list of what shall become multi-lib capable or not.
Chitlesh GOORAH wrote:
On 10/19/06, Denis Leroy <> wrote:
They should do "yum install foo.x86_64" instead of just "yum install foo", also when they update they shouldn't do piecemeal updates.
how about the dependencies yum is fetching ?
Usually those are library deps and a 64 bit app will drag in 64 bit libs etc. The only problem ATM is deps for -devel packages where installing a -devel packages who's base package isn't installed yet will drag in the base package for both archs.
just add this to /etc/yum.conf exclude=*.i386 *.i686 *.i586 *.athlon
Should this be included by default for x86_64 ? user joe won't figure it out like this.
Well that would have meant untill recently no openoffice for example, just excluding anything i386 is not a good idea.
Regards,
Hans
-
Chitlesh GOORAH -
David Nielsen -
Denis Leroy -
Development discussions related to Fedora -
Hans de Goede -
Jesse Keating -
Michael Schwendt -
Patrice Dumas