[Fedora-packaging] fedorakmod.py unfixable (was: atrpms kernel modules)

Axel Thimm Axel.Thimm at ATrpms.net
Sat Aug 12 15:33:10 UTC 2006


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20060812/d51b0fd4/attachment.sig>


More information about the Fedora-packaging mailing list