On Tue, Aug 08, 2006 at 08:06:49PM -0400, Jack Neely wrote:
On Wed, Aug 09, 2006 at 01:42:10AM +0200, Axel Thimm wrote:
> On Tue, Aug 08, 2006 at 06:29:41PM -0400, Jack Neely wrote:
> > I will veto Axel's current plugin as it uses regular expressions to
>
> Let the plugin wars begin ;)
>
> > Most of my hesitation regarding the uname-r in name scheme is because
> > this was fully discussed before and we decided on something different.
> > FESCo ratified it and we were going to be able to support in in FC6 and
> > RHEL 5.
>
> Decisions can be wrong especially when it affects complex matters that
> affects only few packages like less than 0.5% of all packages. The
> important thing is that any decision needs to be reevaluated from time
> to time and possibly changed. Otherwise you kill development.
>
> > There is another important trade off here. Right now
> > up2date/yum/whatever is able to suck down upgraded kernel modules just
> > like upgrades to a new kernel. This works without modifications to the
> > depresolvers because the package name is always the same.
>
> No, you forget that this scheme either nukes or conflicts/coinstalls
> the new modules. Imagine running up2date/yum w/o any kmod-plugin
> support on RHEL5 and nuking your GFS (or AFS) modules away. You (and
> your clients) will not be amused.
Okay...walk me through this then:
Assuming no yum plugins or other mess.
A new kernel is available that corrects some random remote DoS. How do
I get all 1300 machines to pull down the new AFS modules?
It's in the wiki, but here it comes again:
o current kernel module scheme w/o any special depsolver handling:
- broken on rpm level, inherits on all depsolvers
- Modules of the current kernel get nuked whether you reboot into
the new kernel or not
- Module upgrades within the same kernel get blocked due to file
conflicts
- OR module upgrades within the same kernel get coinstalled and
module-init-tools can flip a coin to find out what to choose
+ but the new kernel gets its kernel modules (and only the new
kernel ...)
o proposed kernel module scheme
+ old and current kernels remain untouched by new kernels and kernel
modules for new kernels
+ Proper upgrades of kernel modules within a kernel
- new kernels don't get associated kmdls coinstalled
Now compare and judge for yourself :=)
Next thing to consider is whether and how to fix the remaining issues:
o current kernel module scheme special handling:
- no special handling possible with rpm cli will remain forever
broken
- needs to both mark kernel module packages as coinstallable (which
they are not) and to perform non-rpm comformant depsolving
- Is required for all depsolvers and is a MUST otherwise depsolvers
reduce your system to ashes
o proposed kernel module scheme special handling:
+ nothing needed for rpm cli
+ Obviously less than half the code needed than for the current
scheme, rather trivial coding, easy maintenance
+ Is NICE TO HAVE, absence does not break running system
Compare again. :=)
--
Axel.Thimm at
ATrpms.net