On Wed, 2006-08-16 at 12:43 +0200, Axel Thimm wrote: > I setup an executive summary of the comparison for you and for other > people external to the discussion until now who would like to join in > on Friday: > > http://fedoraproject.org/wiki/AxelThimm/kmdls/kmods_vs_kmdls_at_a_glance I'm almost certainly unable to join any meeting before next week (including tomorrow's packaging and fesco meetings) and will have only very limited access to mail during that time too. It's unlikely that my general opinion about this stuff would change, so it's not really necessary for me to attend the meeting -- don't postpone it for me. To reiterate: if consensus says change is needed, and there's competent manpower available to take care of things *soon*, so be it. The only things I feel strongly about are that rejecting module packages from FC/FE altogether would be profoundly odd at this point, and that the scope of the discussion needs to be limited to whether uname-r gets moved to the packages' names and its direct unavoidable consequences -- the only real technical design issue. Everything else in the "kmdl" proposal is more or less cosmetics and implementation details, and adopting it would mean throwing away quite a bit of work (reinventing the wheel from the POV of the current scheme and its adopters) from several parties for questionable gain. http://fedoraproject.org/wiki/PackagingDrafts/KernelModulesWithKverInName This draft has potential. If it comes down to a vote, mine can be registered as: * -1 for rejecting module packages * +0.5 for moving uname-r *if* there is strong evidence that it will be acceptable for all major stakeholders (Fedora, RHEL, kerneldrivers.org in particular), -0.5 otherwise * -1 to other kmdl change suggestions (BTW, this is off topic, but if this discussion fails to produce useful widely accepted results, I wouldn't outright reject DKMS or DKMS-like mechanisms as an alternative; while these don't meet everyone's requirements, they'd be vastly better than nothing at all.) > While the single items are all factually correct Strong words. The above summary and the detailed doc contains several inaccuracies and omissions (eg. about agnosticity, flexibility, buildsys support, kabi, support(ability) in other distros etc), luckily mostly in the less important parts. I guess this is due to not understanding all aspects of the current scheme and the environment it is designed to work in. I won't spend time detailing those because I don't have time to do that right now, and even if I had, IMO there are no real reasons to consider/discuss its adoption besides the uname-r move bit. (Yes, sucky statement, but shrug, it's the best I can do in the time I have available for this at the moment.) -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
