On Mon, Aug 14, 2006 at 01:19:32PM -0400, Jesse Keating wrote: > On Friday 11 August 2006 06:58, Axel Thimm wrote: > > I suggest to vote through email about replacing the current kernel > > scheme with the kmdl or similar scheme. > > Perhaps I'm dumb, but after reading your wiki page I'm still not seeing where > the current scheme really falls over. We have kmod packages treated like > kernel packages in that they are install rather than upgrade. This is the > same way that the kernel is handled, and if people do silly things with the > rpm command line they can break their kernel just as easily as they can break > their kernel modules. No, the issue is that kernel modules packages are neither to be "coinstalled", nor to be "upgraded" if the package entity is not disambiguated w/ uname-r-in-name I've give such an exmaple before, try writing down an rpm command for the following situation: Installed: kernel-a module-2-for-a kernel-b module-1-for-b Now try to install module-2-for-b. For kmdls it's just rpm -U. For kmods it's impossible, you need to coinstall with module-2-for-a but upgrade module-1-for-b. That's why every depsolver suddenly needs a plugin to do anything at all with kmods. The plugin needs to take this awkward situation in account and undo things that yum considered sane to do (but yum was only following rpm logic). But the argument goes on that once you pull in a package "by mistake" you cannot undo it unless it is trivial e.g. has no further package depedencies like requires/obsoletes/conflict. These cascade further changes in yum's dependency resolver and undoing them in a plugin effectivly lead to redesigning yum in the plugin. Currently the plugin assumes that is not the case, which is the case with wireless/v4l/gfs/cluster/firmware support etc. So the plugin will fail in these cases. And any plugin for any other depsolver will fail the same and rpm doesn't have plugins. The net result is a half-working yum, borken rpm, broken smart etc. In comtrast if the scheme respects rpm rules like the kmdl scheme does you don't need to undo yum's work, just add the coinstall support. It turns out that the plugin for kmdls was less than half the current plugin for kmods which performs less and is still broken as outlined above. > We have this handling in yum, which is the basis of every depsolver > we support in Fedora / Red Hat. Yum is used by pup, puplet, pirut, > and anaconda. All of these make use of the special casing we have > in Yum and handle kmods correctly by installing rather than > upgrading them. Thanks for the list. This means all of them are currently broken as outlined. And all of them can be fixed by following basic rpm rules like the kmdls do. The key point here is uname-r-in-name. > If other depsolvers don't, well that's really too bad and its up to > those depsolvers to handle the packages correctly like they (should) > handle kernel packages correctly. I agree, if rpm and yum/pup/etc *could* deal with it, but they don't. > So, I guess I'm being dumb, and I need it spelled out in big foam > letters as I'm just not getting it, and thus I can't vote on it. Is the example above & argumentation clear? If yes, and the wiki is not please suggest where to inject an example or soem more working in the wiki. -- Axel.Thimm at ATrpms.net
Attachment:
pgpQz9JuaDym6.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
