[repo-coord] Re: nVidia rpms ...

[Axel Thimm]

This kind of bug is probably of interest to all multiarch repo
maintainers, Ccing repo-coord.

I will, seeing that I just did a ...
yum --enablerepo=at-stable install
kernel-module-nvidia-graphics6629-`uname -r` nvidia-graphics6629
I did get a few errors,

Hm, something about /usr/lib/nvidia-graphics-helpers/nvidia-config-x.py?
In this case call
/usr/lib64/nvidia-graphics-helpers/nvidia-config-x.py
and move the generated /etc/X11/xorg.conf.nvidia over to
/etc/X11/xorg.conf (after checking that the changes are OK).

The reason for the bug above is that I am placing all i386 rpms into
the x86_64 repo as well. yum (and perhaps up2date?) always installs
both rpms if not explicitely told the arch.

Probably yum's behaviour is correct, the assumption is that a x86_64
repo only contains those compatibility packages that are really
required. If you need more, you can still include an i386 repo
directly.

So perhaps we should carefully decide which i386 packages to add to
x86_64 repos? It would be interesting to know how Red Hat decided
which packages to offer as i386 compatibility packages. Probably all
openoffice depends on, but perhaps there are more.

[Dag Wieers]

Post by Axel Thimm
This kind of bug is probably of interest to all multiarch repo
maintainers, Ccing repo-coord.

I will, seeing that I just did a ...
yum --enablerepo=at-stable install
kernel-module-nvidia-graphics6629-`uname -r` nvidia-graphics6629
I did get a few errors,

Hm, something about /usr/lib/nvidia-graphics-helpers/nvidia-config-x.py?
In this case call
/usr/lib64/nvidia-graphics-helpers/nvidia-config-x.py
and move the generated /etc/X11/xorg.conf.nvidia over to
/etc/X11/xorg.conf (after checking that the changes are OK).

The reason for the bug above is that I am placing all i386 rpms into
the x86_64 repo as well. yum (and perhaps up2date?) always installs
both rpms if not explicitely told the arch.
Probably yum's behaviour is correct, the assumption is that a x86_64
repo only contains those compatibility packages that are really
required. If you need more, you can still include an i386 repo
directly.
So perhaps we should carefully decide which i386 packages to add to
x86_64 repos? It would be interesting to know how Red Hat decided
which packages to offer as i386 compatibility packages. Probably all
openoffice depends on, but perhaps there are more.

I refuse. The behaviour of Yum is clearly broken, people do not expect to
have all binary archs installed just because they are available and the
arch is unspecified. People are not supposed to know in what archs a
package comes.

There are many reasons why the current design is broken from a user point
of view. A user does not know what architectures are available, nor does
he know whether a package is binary or noarch. It should not matter to
him, if he needs a package, Yum should first try x86_64, then i386, then
noarch. Unless arch is explicitly specified (either on commandline or by
dependency)

Furthermore, it's problematic to only provide what _your_ packages
require. This means you cannot provide i386 packages for whatever other
application might need.

I've taken this up with Seth a few days after the release of FC3 and it
was apparently intentionally designed like that and we had the usual
Yum-squarel.

This is yet another item forcing the burden on repository maintainers
where the tool could allow for much more flexibility and less problems.
Besides, there is no tool currently that offers a solution for repository
maintainers, and it's impossible to handle this manually.

-- dag wieers, ***@wieers.com, http://dag.wieers.com/ --
[all I want is a warm bed and a kind word and unlimited power]

[Axel Thimm]

Post by Dag Wieers

Post by Axel Thimm
The reason for the bug above is that I am placing all i386 rpms into
the x86_64 repo as well. yum (and perhaps up2date?) always installs
both rpms if not explicitely told the arch. [...]
So perhaps we should carefully decide which i386 packages to add
to x86_64 repos? [...]

I refuse. The behaviour of Yum is clearly broken, people do not
expect to have all binary archs installed just because they are
available and the arch is unspecified. People are not supposed to
know in what archs a package comes.
There are many reasons why the current design is broken from a user
point of view. A user does not know what architectures are
available, nor does he know whether a package is binary or
noarch. It should not matter to him, if he needs a package, Yum
should first try x86_64, then i386, then noarch. Unless arch is
explicitly specified (either on commandline or by dependency)
Furthermore, it's problematic to only provide what _your_ packages
require. This means you cannot provide i386 packages for whatever
other application might need.

I agree with you, and raising this up to the appropriate places is the
most proper thing to do. But what is the appropriate/authoritative
place? The yum author implements what he thinks is best, so does the
up2date/apt/whatever author. The concept of a multiarch/compatibility
arch repo was never discussed in open, perhaps never even cleanly
conceived, but simply hacked in place.

Perhaps the folks in repo-coord agree to a common concept. Personally
I go with whatever works.

Post by Dag Wieers
I've taken this up with Seth a few days after the release of FC3 and it
was apparently intentionally designed like that and we had the usual
Yum-squarel.

OK, I should have searched the archives (yum? fedora-devel?).

Post by Dag Wieers
This is yet another item forcing the burden on repository maintainers
where the tool could allow for much more flexibility and less problems.
Besides, there is no tool currently that offers a solution for repository
maintainers, and it's impossible to handle this manually.

What do you suggest from a pragmatic POV? I don't want to be burried
under x86_64 bug reports because the package resolver installs all
i386 packages as well.

BTW for the interested: It is possible to install FC2/x86_64 and
FC3/x86_64 w/o any multilib, then you also have apt at your
disposal. For FC2/x86_64 you need a patched grub like the one at

http://atrpms.net/dist/fc2/grub/

But for the multilib systems we only have yum/up2date for installing
packages, with their bugs/features.

Post by Dag Wieers
[all I want is a warm bed and a kind word and unlimited power]
_______________________________________________
repo-coord mailing list
http://lists.atrpms.net/mailman/listinfo/repo-coord

[Panu Matilainen]

Post by Dag Wieers

Post by Axel Thimm
So perhaps we should carefully decide which i386 packages to add to
x86_64 repos? It would be interesting to know how Red Hat decided
which packages to offer as i386 compatibility packages. Probably all
openoffice depends on, but perhaps there are more.

I refuse. The behaviour of Yum is clearly broken, people do not expect to
have all binary archs installed just because they are available and the
arch is unspecified. People are not supposed to know in what archs a
package comes.

The problem is with the multilib monster and RH packaging, not yum. If
the you have libfoo.i386 and libfoo.x86_64 which don't share any files
then installing separately is not a problem. However several such
packages in FC and RHEL do have common files, in which case installing
them separately fails with file conflicts (and you need to use --force
to override, sometimes with "interesting" results) but if they're
installed simultaneously rpmlib just "swallows" the conflict. Multilib
isn't called sick without a reason...

- Panu -

[seth vidal]

Post by Panu Matilainen

Post by Dag Wieers

Post by Axel Thimm
So perhaps we should carefully decide which i386 packages to add to
x86_64 repos? It would be interesting to know how Red Hat decided
which packages to offer as i386 compatibility packages. Probably all
openoffice depends on, but perhaps there are more.

I refuse. The behaviour of Yum is clearly broken, people do not expect to
have all binary archs installed just because they are available and the
arch is unspecified. People are not supposed to know in what archs a
package comes.

The problem is with the multilib monster and RH packaging, not yum. If
the you have libfoo.i386 and libfoo.x86_64 which don't share any files
then installing separately is not a problem. However several such
packages in FC and RHEL do have common files, in which case installing
them separately fails with file conflicts (and you need to use --force
to override, sometimes with "interesting" results) but if they're
installed simultaneously rpmlib just "swallows" the conflict. Multilib
isn't called sick without a reason...

There's also an issue of consistency of interface:

yum splits the concept of acceptable arches for into two branches ,
right now, which is more or less the 64bit arches and the 32bit arches

That's so it can compare the 32bit arches against each either to find
the 'best' one for 32bit and the same for the 64bit arches. But so
they're not compared against each other.

so since yum install foo on an i686 installs the best arch of foo for
the arch branches available - it stands to reason, at least to me, that
you'd want BOTH multiarch branches on a multiarch machine.

If you want to be more specific then you should specify the arch on the
command line:
yum install foo.x86_64

this also makes a bit more sense when you compare it to the remove
command:

yum remove foo

will remove all the installed archs.

not just the 64bit arch

-sv

[Axel Thimm]

Post by seth vidal

Post by Panu Matilainen

Post by Dag Wieers

Post by Axel Thimm
So perhaps we should carefully decide which i386 packages to add to
x86_64 repos? [...]

I refuse. The behaviour of Yum is clearly broken, people do not
expect to have all binary archs installed just because they are
available and the arch is unspecified. People are not supposed
to know in what archs a package comes.

The problem is with the multilib monster and RH packaging, not
yum. If the you have libfoo.i386 and libfoo.x86_64 which don't
share any files then installing separately is not a
problem. However several such packages in FC and RHEL do have
common files, in which case installing them separately fails with
file conflicts (and you need to use --force to override, sometimes
with "interesting" results) but if they're installed
simultaneously rpmlib just "swallows" the conflict. Multilib isn't
called sick without a reason...

yum splits the concept of acceptable arches for into two branches ,
right now, which is more or less the 64bit arches and the 32bit arches
That's so it can compare the 32bit arches against each either to find
the 'best' one for 32bit and the same for the 64bit arches. But so
they're not compared against each other.
so since yum install foo on an i686 installs the best arch of foo for
the arch branches available - it stands to reason, at least to me, that
you'd want BOTH multiarch branches on a multiarch machine.
If you want to be more specific then you should specify the arch on the
yum install foo.x86_64

Could yum have a switch to toggle between
when-I-skip-the-arch-pull-all-archs and
when-I-skip-the-arch-pull-native-only?

All x86_64 repos will also have an i386 repo. There are three modes of
operation:
o keep them separate. But sometimes users do need i386 on x86_64, so
they would activate the i386 repo and we get to the next model:
o Put them into one (currently practice outside of RH). You get too
much for what you asked.
o Have the repo maintainer hand pick the interesting i386 packages to
add to the x86_64 repo (like RH does). This will be error prone, of
course, and still some users may require more and get back to the
second model.

I'd prefer putting it all into one basket and have the resolver pick a
minimal set of (native) packages, unless told otherwise. If a switch
in yum.conf like compatarchs = [always|minimal] could be created, that
would be great. Is there any chance for that?

Post by seth vidal
this also makes a bit more sense when you compare it to the remove
yum remove foo
will remove all the installed archs.
not just the 64bit arch
_______________________________________________
repo-coord mailing list
http://lists.atrpms.net/mailman/listinfo/repo-coord

[Dag Wieers]

Post by Panu Matilainen

Post by Dag Wieers

Post by Axel Thimm
So perhaps we should carefully decide which i386 packages to add to
x86_64 repos? It would be interesting to know how Red Hat decided
which packages to offer as i386 compatibility packages. Probably all
openoffice depends on, but perhaps there are more.

I refuse. The behaviour of Yum is clearly broken, people do not expect to
have all binary archs installed just because they are available and the
arch is unspecified. People are not supposed to know in what archs a
package comes.

The problem is with the multilib monster and RH packaging, not yum. If
the you have libfoo.i386 and libfoo.x86_64 which don't share any files
then installing separately is not a problem. However several such
packages in FC and RHEL do have common files, in which case installing
them separately fails with file conflicts (and you need to use --force
to override, sometimes with "interesting" results) but if they're
installed simultaneously rpmlib just "swallows" the conflict. Multilib
isn't called sick without a reason...

But these packages with common files that have existed before don't suffer
from the same problem as is the case with multilib packages ? Couldn't the
same work-around be implemented, whatever that is/was ?

I'm sure there's room for doing it differently than what rpm allows, ie.
rpm is very strict about some other things that have been successfully
hidden from end-users in the past. Not handling this better (then
installing both) is a burden for repository maintainers and often even
impossible to satisfy. (ie. there's not automatic way to know that mozilla
plugins should be included as i386 too).

-- dag wieers, ***@wieers.com, http://dag.wieers.com/ --
[all I want is a warm bed and a kind word and unlimited power]