[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