future kernel module rpm situation (was: kernel-source vs. kernel-sourcecode (please revert))

Axel Thimm Axel.Thimm at ATrpms.net
Tue Jun 15 14:53:40 UTC 2004


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040615/d6cb6a9a/attachment.sig>


More information about the fedora-devel-list mailing list