On Tue, 15 Jun 2004, Dax Kelson wrote: > On Tue, 2004-06-15 at 19:13 +0200, Arjan van de Ven wrote: > > On Tue, Jun 15, 2004 at 11:05:11AM -0600, Dax Kelson wrote: > > > > tree updates come from, and remain stable at all times. That avoids double > > > > work an missed bugfixes > > > > > > Having kernel-source become noarch is a non-issue from the impact on > > > ISVs. The renaming is the problem. > > > > I rather not have renamed it either, however the impact should have been > > low; only people who want to build their entire new kernel use > > kernel-source (or should). Yum now can at least get to the new package, > > which was the sole reason for the rename (well together with up2date) > > So it is doable to push out new yum and up2date, and then go back to the > old, standard, kernel-source name for the next kernel release? Dunno if you followed my and skvidals discussion about this: fixing this *right* in the depsolvers isn't that trivial. It's a good idea to have protection against out-of-sync mirrors so that you wont end up with i386 glibc on NPTL system which totally hoses things up, that's why up has exactarch=1 set by default (dunno if up2date can turn that behavior off at all .. hmm there's --arch=<arch> option which could've been used as a temporary workaround). But that effectively prevents on-purpose arch "downgrades" which rarely happen but occasionally do. That said, since it only affects people who want to build their own kernels: IMHO would've caused much less general pain to tell those people to temporarily do <description for each client> to get around it than change a longstanding package name. Oh well, cat's out of the bag, changing back now would create even more annoying corner case: "the package is kernel-source except for this one kernel-release where it's kernel-sourcecode". - Panu - >