[Fedora-packaging] Re: Mail voting on kmdl adoption

[Jack Neely]

On Mon, Aug 14, 2006 at 08:44:08AM -0500, Tom 'spot' Callaway wrote:
> On Sat, 2006-08-12 at 17:18 +0200, Axel Thimm wrote:
> > On Sat, Aug 12, 2006 at 09:31:04AM -0400, Jesse Keating wrote:
> > > On Saturday 12 August 2006 08:14, Panu Matilainen wrote:
> > > > Both choices have their weak and strong points. If it's impossible
> > > > to decide based on technical merits alone... flip a coin or
> > > > something, really.
> > > 
> > > Or continue to use the current one that is being used by current
> > > packages in Extras, and in RHEL.
> > 
> > and which cannot be used for manual rpm installations, breaks all
> > depsolvers, endangers your running setup or the total upgradablity of
> > the system and the ugly workarounds trying to fix this turn out to
> > introduce more bugs that they fix making the depsolver support a
> > maintenance nightmare.
> 
> To be fair, the only change to kmod that would be necessary to remove
> all of this "it won't work for manual rpm installations" is the addition
> of kver in the Name field.
> 
> So far, the only technical reason that I've heard mentioned here against
> adding kver to Name is that it would make debuginfo more complicated for
> kmod packages (and I believe that someone posted a workaround method).
> In fact, I suspect that kmodtool could even include the necessary magic.
> 
> ~spot
> -- 
> Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260
> Fedora Extras Steering Committee Member (RPM Standards and Practices)
> Aurora Linux Project Leader: http://auroralinux.org
> Lemurs, llamas, and sparcs, oh my!
> 

No one has offered an explanation or yum plugin to handle scalability.
A new kernel is released.  How do I push out a new kernel module to all
my machines?  This scheme only appears to scale to 1 person with root on
his home machine.  I need to power an entire university.

Because kmdl modules do not follow the kernel that adds yet another
reason why upgrading to the latest kernel is painful and to be avoided.
We all know where this slippery slope goes.

Jack

-- 
Jack Neely <jjneely at ncsu.edu>
Campus Linux Services Project Lead
Information Technology Division, NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4  EA6B 213B 765F 3B6A 5B89