On Tue, 2007-10-09 at 20:43 -0400, Jeremy Katz wrote: > On Tue, 2007-10-09 at 20:27 -0400, seth vidal wrote: > > On Tue, 2007-10-09 at 17:07 -0400, Jeremy Katz wrote: > > > Currently on multiarch systems, you can end up getting a new arch of a > > > package pulled in if it's done via an obsolete rather than an update > > > (rh#301661). The attached patch is a first crack at making the behavior > > > for obsoletes match that of updates. Best way to make clearer is > > > probably an example... > > > > > > On your x86_64 system, you removed all i386 packages. Now, there is a > > > new NetworkManager package which obsoletes dhcdbd. The repository > > > contains NetworkManager.i386 and NetworkManager.x86_64. With the > > > current code, you end up with both x86_64 and i386 packages installed. > > > With the attached patch, you'll only get NetworkManager.x86_64. > > > > > > I've double checked that arch changing works (ie, NetworkManager.i386 is > > > the only thing in the repo and it obsoletes dhcdbd.x86_64) and I can't > > > see any reason this would break. > > > > Just at first glance this looks like that foo.noarch won't be able to > > obsolete bar.i386, though. I'll do a test in a few but have you already > > checked that? > > foo.noarch won't obsolete bar.i386 only if there's also a foo.i386. Now > for dinner.
so isn't this a non-starter, then? If we don't let noarch ->arch and arch->noarch obsoletes then we'll be regressing vs current behavior. -sv _______________________________________________ Yum-devel mailing list [email protected] https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
