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 -