multilib repos (was: nVidia rpms ...)

--===============0359139696092237522==
Content-Disposition: inline
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="4vgOdmpzXGVCiUly"


--4vgOdmpzXGVCiUly
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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? [...]
>=20
> 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.
>=20
> 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)
>=20
> 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=
=20
> was apparently intentionally designed like that and we had the usual=20
> Yum-squarel.

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

> This is yet another item forcing the burden on repository maintainers=20
> where the tool could allow for much more flexibility and less problems.
> Besides, there is no tool currently that offers a solution for repository=
=20
> 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]
>=20
> _______________________________________________
> repo-coord mailing list
> [email protected]
> http://lists.atrpms.net/mailman/listinfo/repo-coord

--=20
Axel.Thimm at ATrpms.net

--4vgOdmpzXGVCiUly
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFBsFh2QBVS1GOamfERAkMZAKCa4HgogBVflTjJE5cgoadmsmi5hgCeOSS4
HYo8GKuHXxiTos4vucc1GrY=
=cthu
-----END PGP SIGNATURE-----

--4vgOdmpzXGVCiUly--


--===============0359139696092237522==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
repo-coord mailing list
[email protected]
http://lists.atrpms.net/mailman/listinfo/repo-coord

--===============0359139696092237522==--