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
Attachment:
pgpfPTOsw9sc7.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
