[Fedora-packaging] Updated kernel-module-packaging example with ndiswrapper (Was: example kernel-module package)

[Ville Skyttä]

On Sun, 2005-07-03 at 19:10 +0200, Thorsten Leemhuis wrote:
> Am Sonntag, den 03.07.2005, 19:12 +0300 schrieb Ville Skyttä:
>
> > A policy or at least guidelines exactly where to place the modules
> > below /lib/modules/%{kver} would be nice. 
> 
> Yes.
> 
> My proposal: [...]

I forgot to mention that I don't have strong opinions on this, as long
as some understandable guidelines exist.  Installing into whatever
upstream uses by default does have its merits like you pointed out.

> > Except as described in my earlier mail to this thread, if the main
> > package's NVR doesn't change between rebuilds, we have a problem with
> > -debuginfo for these builds.
> > https://www.redhat.com/archives/fedora-packaging/2005-June/msg00055.html
> 
> Uhh, sorry, I knew I was forgetting something. Yes, that should be
> fixed. So what are our options:
> 
> 1) create the debug-pkg ourself and don't rely on the internal rpm
> solution.

Urgh, have you looked at glibc.spec?  We really don't want that in every
kernel module package.  Perhaps it's acceptable if we could just call a
script somewhere and be done with it.

But the fundamental problem isn't actually limited to -debuginfo, but
affects SRPMs to some extent as well (same-NEVR'd SRPM from different
builds - what to do with them?).  See below.

> 2) use a spec similar two my first proposal where the actual source of
> the kernel-module is in an external rpm that is a BuildRequire.

I still don't like this too much in principle, but all the alternatives
seem to have shortcomings of their own as well, so it seems we need to
pick the least bad alternative.  And this is a definite candidate.  If I
understand correctly, the binary-containing-source package could be
theoretically reused in DKMS and similar systems - that would make this
approach even more attractive.

> 3) No sub-pkg -- gives a lot of SRPMS that might take a lot of space...

Theoretically, we can choose to not ship these SRPMS at all.  Their
rebuild results vary depending on the passed in (or detected, in case of
local rebuilds) kver anyway; what it was at build time won't affect the
results.  So essentially they're just the same things except for the
filename of the SRPM.  OTOH, not shipping them sounds fundamentally
wrong.

In the meantime, status of kernel-module-thinkpad in CVS:
- The SRPM duplication (non?)problem persists.
- It can be built for the running kernel without specifying kver, but 
  the -debuginfo problem and the problem of getting same-NEVR'd source
  packages from different (specfile based) builds bites then.  This 
  would not affect us, I assume we will always pass kver.  And the
  problem would be trivially solved by just removing the possibility
  to build without specifying kver.

I'm starting to think that Thorsten's 2) above would actually solve all
our problems, even if it's hackish, not the pretties one and it's a bit
hard to understand.