On Tue, Jun 15, 2004 at 12:40:40PM +0200, Axel Thimm wrote: > And yum already has support for this (or not?). Just set exactarch to > 0 in yum.conf. exactarch is a problem anyhow, when for instance athlon > packages get consolidated into i686 package like the kernel in FC2. On Tue, Jun 15, 2004 at 04:24:02PM +0200, Axel Thimm wrote: > On Tue, Jun 15, 2004 at 10:07:25AM -0400, seth vidal wrote: > > As have I - remember all the nptl problems people saw in rhl9-era? A > > fair number of those were apt switching from glibc.i686 to glibc.i386 > > midstream. > > which was a bug in the repo (the updates repo) not providing the same > NEVR, but uploading i386 first. > > How will yum handle athlon downgrades to i686 or i386? Yes, there are > no such packages in download.fedora.redhat.com (other than FC1 > kernels), but such packages exist, and should the package maintainers > also have to rename their packages for changing the arch? On Tue, Jun 15, 2004 at 10:25:57AM -0400, seth vidal wrote: > set exactarch=0 and yum will gladly 'downgrade' arch changes in > packages. Yes, I know (see above), but obviously arch locking is not a good solution for all packages. As you say, it was invented to work around mirror desyncronization (for the nptl issues it would have been better to have nptl'd glibc and kernel to be conflicting against non-nptl matches. That would have worked independent of the resolver, which is the right way to treat any such issues. Just as a sidenote, because the treat of this issue from high level tools like yum/apt etc. results in troubles like the current issues). I, too, am very fond of Matthias' suggestion to have exactarch effectivly a per package option. -- Axel.Thimm at ATrpms.net
Attachment:
pgpzR2VaZXvZy.pgp
Description: PGP signature
