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.
Workaround 1: assume rpm -i is in order, add "kernel-modules"
coinstall support in yum proper
Workaround 2: find out that the coinstall support is not enough,
additionally write a plugin
Workaround 3: find out that rpm -i isn't the proper mode, try to fix
the plugin for yum, despair on rpm
Workaround 4: find out that the plugin for yum is still incomplete and
possibly cannot be ever fixed.
Workaround 5: Impose restrictions on kernel modules and their usage so
that unfixable bugs are not triggered [*].
In contrast to well behaved rpm, yum and all other from the very start
and a trivial plugin to make yum usage more comfortable not even
needeing special "kernel-modules" support?
FYI there is exatly 1 (one) package in extras using the kernel module
scheme and RHEL is just being taught kmods (GFS) - it's not too late to
avoid RHEL5 ship with such a broken scheme unless we decide to discuss
this forever.
[*] Like
- never use rpm cli
- never have dependencies of kernel module packages on other
packages (breaks GFS/cman/dlm/...)
--
Axel.Thimm at ATrpms.net
Attachment:
pgppd7vHOxWDi.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
