[Fedora-packaging] Re: Kernel Module Packaging Standard Teleconference

[Ville Skyttä]

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.)