kernel-source vs. kernel-sourcecode (please revert)

[Panu Matilainen]

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 -
>