[Fedora-packaging] fedorakmod.py unfixable (was: atrpms kernel modules)
Hi Jack,
can you please answer on the statement below that wrt fedorakmod.py
plugin if the wrongly tagged kernel module packages pull in other
packages through dependencies you're hosed up?
Explenation for the others: That's because the plugin works in such a
way that it needs to allow yum to perform the proper transaction setup
which includes tagging kernel module packages for installation that
should not had been tagged according to the kmod scheme (but that's
not yum's fault, yum is just being rpm compatible).
So the plugin tries to remove again these packages before the
transaction is commited. But it doesn't take into account that these
packages may have further dependencies and may have pulled in more
packages, which currently is not checked and I doubt that one can ever
identify them.
Just to name real-world cases where kmdls pull in other kmdls and
userland bits where this plugin would fail: GFS/cman/dlm, ivtv/v4ldvb,
ipw3495{,d} packages, ipw*/ieee80211.
Please make a statement about that as this demonstrates that the
plugin has unfixable flaws - which is neither yum's not the plugin's
fault, it is just the mirroring of allowing an rpm-incompatible
kernel module scheme.
I hope the correctness and maintenance issues here will persuade the
last kmdl opponent. :)
On Mon, Aug 07, 2006 at 04:54:14PM +0200, Axel Thimm wrote:
On Mon, Aug 07, 2006 at 10:00:13AM -0400, Jack Neely wrote:
> > So any raised issue on the naming/versioning of kernel module packages
> > still remains as discussed - including non-rpm conformant behaviour of
> > such packages with the rpm -U/-i nuke/conflict situation, which is still
> > not "fixed" on yum level or any other depsolver's (and having
looked
> > into yum's plugin system which is quite nice BTW, I don't know whether
> > it will be "fixable" at all)
>
> If the existing fedorakmod.py plugin in yum-utils does not handle
> installs, upgrades, and co-installs of kmod style kernel modules then
> I'd like a detailed bug report please.
AFAIU yum's plugin logic in order to perform according to the current
rpm-level-broken kernel module scheme a plugin would have to undo
parts of yum's transaction. E.g. yum does not offer a hook to
manipulate its logic during the depsolving. Note that yum's depsolver
logic is rpm conformant. Therefore the moment the fedorakmod.py takes
over the transaction set may contain both nuking and conflicts which
the plugin needs to address in retrospective now.
Coinstall support "solves" the first issue, but the second issue is
only "solvable" by removing parts of the transaction. Unfortunately
removing is an operation that needs to get back into the depsolver
logic - unless the package to be removed has no further dependent or
depending on packages. This may be true for most of the current few
available kernel modules in this scheme, but there are others that
have richer depedendency structure - most notably v4l2 and wifi
related modules.
It doesn't look like the fedorakmod.py plugin takes that into
account. It's still "fixable" by adding even more code, but it's
already gaining code size and therefore maintenance costs for
something that wasn't "broken" to begin with. This also shows that
there may be even more bugs lurking, and this is only the support for
yum, rpm still remains "broken" and so do all the other depsolvers.
It's nothing against Jack's work or even Thorsten's and Ville's work
on the kernel module specs. It's just a core design element that
proves to be bad and needs replacement asap.
I know I repeat myself, but:
There is the kmdl proposal which doesn't even need any special plugins
to remain rpm-compliant for both rpm and all depsolvers and while
support for coinstalls for new kernels is missing in all depsolvers it
proved to be trivial to add a < 100 lines easy to maintain plugin to
accomplish that. So there really is only the I-don't-like-uname-r-
in-name issue left ...
--
Axel.Thimm at ATrpms.net
Attachments:
- attachment.sig (application/pgp-signature — 189 bytes)