[repo-coord] multilib repos (was: nVidia rpms ...)
Axel Thimm
Axel.Thimm at atrpms.net
Fri Dec 3 13:13:42 CET 2004
On Fri, Dec 03, 2004 at 12:29:32PM +0100, Dag Wieers wrote:
> On Fri, 3 Dec 2004, Axel Thimm wrote:
> > 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.
> 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?).
> 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.
> [all I want is a warm bed and a kind word and unlimited power]
>
> _______________________________________________
> repo-coord mailing list
> repo-coord at atrpms.net
> http://lists.atrpms.net/mailman/listinfo/repo-coord
--
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.atrpms.net/pipermail/repo-coord/attachments/20041203/8e3d1a26/attachment.bin
More information about the repo-coord
mailing list