On Mon, Aug 14, 2006 at 02:31:41PM -0400, Jesse Keating wrote: > Seems to me that we're really trying to beat around a deficiency in RPM. Yes, that's pinned down nicely by tibbs as making rpm two-dimensional. But that's what we've got and it is not going to change for a long time. > Creating whole new packages for every single kernel release is insane. New > cvs modules, new bugzilla entries, new ownerships, etc, etc, etc.. Our > entire infrastructure is based around the name of a package. Changing that > for every single kernel update, or special casing it in every system is just > silly. REALLY silly. I will absolutely vote against it. As outlined by Panu this is not the case. In fact the infrastructure and maintenance is halfed as there is really only one name, not two like it is today. The kmod standard need two bugzilla entries per package, two owner entries, two cvs modules. kmdls only need one. So may I take that as a vote in favour of a one-sepcfile design? :) > > 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. > > I have read these two paragraphs 5 times, and I still don't understand what > you are saying. Examples work wonders. I'm lost in hyperbole land. OK, suppose some kernel module scheme like kmod works against yum's depsolving. Since yum adhears to rpm orderign and the kmod scheme doesn't that's not difficult to achive. Now the setup is such that yum will either install too many or to few packages. Too few is good, you can always add to yum's transaction and yum will compute the new dependencies. Too much is really bad, because the pulled in packages will pull in more packages or push out others (due to Requires/Obsoletes/Conflicts). Let's get to an example: ipw3945 version X (the exmaple is real, but don't have me lookup the true versions please) requires ipw3945d Y (a userland daemon). ipw3945 X+1 requires ipw3945d Y+1. If yum "wrongly" tries to pull in ipw3945-X this will have pulled in ipw3945d-Y. Undoing this in some plugin code would only remove ipw3945-X, not ipw3945d-Y. Further examples are ivtv/v4l2, ipw2*/ieee80211, ipw2*/firmware etc. > You're working around an issue in rpm by creating new packages all the time. > That's not a solution, that's an ugly hack. The packages are really distinct and have different functionality and depednencies. You need both evrs in the total package filename. Moving them to the rpm name turns to solve 95% of all issues. And the fears on increased infrastructure are unbased, you even save some. > Thanks, I've heard enough to make up my mind. -1 on the entire thing. OK, is that still the case after having seen that infrastructure is not bitten? -- Axel.Thimm at ATrpms.net
Attachment:
pgpWyvCQQMvCc.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
