Re: Updated kernel-module-packaging example with ndiswrapper (Was: example kernel-module package)

On Mon, 2005-07-04 at 09:30 -0500, Tom 'spot' Callaway wrote:
> On Sun, 2005-07-03 at 21:01 +0200, Thorsten Leemhuis wrote:
> 
> > > 1) create the debug-pkg ourself and don't rely on the internal rpm
> > > solution.
> > [...]
> > > If 1) is easy I'll vote for that.
> > 
> > I tried, was not that hard (if I didn't miss anything). Results are
> > found at
> > http://www.leemhuis.info/files/fedorarpms/MISC.fdr/kernel-module-example/
> > in the wiki at
> > http://www.fedoraproject.org/wiki/Extras/KernelModuleProposal
> 
> I like this approach the best.

I like that too, but the dilemma with the same-NEVR'd source rpm
persists.  I'm not sure if it's a design goal or a design flaw, but the
little (ha!) pedant in me says it's the latter.  To clarify:

- kernel-module-foo-1.0-1.src.rpm in repo
- check out the package from CVS, build for a new kernel
  -> get another kernel-module-foo-1.0-1.src.rpm which != the original

What to do with the new source rpm?  Discarding would be ugly, and
overwriting the existing srpm in the repo even uglier.  Rebuilding from
an existing srpm in the repo would help (or just pretending it was done,
and discarding the new one :)).

Allowing the source rpm's NEVR to change between rebuilds as usual and
always shipping them would not have this problem at the (negligible
IMHO) cost of more disk space consumption.  That approach would not need
any special -debuginfo treatment either.

In this scenario, we'd just need to figure out how we'd like the CVS
tags to be.  Turning things upside down and explicitly specifying a
default %{kver} assignment in specfiles when new kernels are released (+
the smp etc variants each separately) and allowing local rebuilders
override it with a --define would solve that easily, with the added
benefit that the build system wouldn't have to know about passing any
special --defines to these builds.   Whoever requests the builds would
just have to be able to specify the target architecture(s).  As an
example, I've changed kernel-module-thinkpad in Extras CVS (devel) to do
the above (currently for the UP build).

Mmh, maybe I should just shut up about this now :).  Does the above make
any sense?

> The only change is that the -debuginfo
> package needs to Require: kernel-module-%{mainpkgname} (its not any good
> without it).

Note: -debuginfo packages created the usual way don't have that
dependency.  But that's probably because it could be hard to implement
in the automagic that generates them nowadays.  If such a dependency
would be added, it should be fully versioned, though.

> As to location, I'm very inclined to standardize on:
> /lib/modules/%{kver}/extra/%{mainpkgname}

Works for me.