On Mon, 2006-08-14 at 14:31 -0400, Jesse Keating wrote:
On Monday 14 August 2006 14:16, Axel Thimm wrote:
> No, the issue is that kernel modules packages are neither to be
> "coinstalled", nor to be "upgraded" if the package entity is
not
> disambiguated w/ uname-r-in-name
>
> I've give such an exmaple before, try writing down an rpm command for
> the following situation:
>
> Installed:
>
> kernel-a
> module-2-for-a
>
> kernel-b
> module-1-for-b
>
> Now try to install module-2-for-b. For kmdls it's just rpm -U. For
> kmods it's impossible, you need to coinstall with module-2-for-a but
> upgrade module-1-for-b.
>
> That's why every depsolver suddenly needs a plugin to do anything at
> all with kmods. The plugin needs to take this awkward situation in
> account and undo things that yum considered sane to do (but yum was
> only following rpm logic).
Seems to me that we're really trying to beat around a deficiency in RPM.
Creating whole new packages for every single kernel release is insane. New
cvs modules, new bugzilla entries, new ownerships, etc, etc, etc.. Our
entire infrastructure is based around the name of a package. Changing that
for every single kernel update, or special casing it in every system is just
silly. REALLY silly. I will absolutely vote against it.
The entire infrastructure is based around the name of the SOURCE package
which remains the same with kmdls just like with kmods, normal
subpackage splits etc.
- Panu -