On 13/01/2019 16:18, drake763 wrote:
Thanks again for your quick and detailed response!
On 1/13/19 2:49 PM, Gianfranco Costamagna wrote:
Now, dkms run on amd64 produces binaries for *amd64* architecture, and if you
run the same command
on i386 you will produce kernel modules that can run only on *i386* architecture
In my understanding, running in some src directory (which has to support
this obviously)
make dkms_mkdeb
produces an architecture independent deb package (hence my thought to
have the suffix _all.deb). When I then install that very _all.deb
package with dpkg, DKMS is invoked again and the actual compilation
takes place where the architecture dependent binary is produced (so dkms
is invoked twice. Once when creating the package, and again when installing)
My usecase is applying this patch for intel processors
(http://linux-phc.org/forum/viewtopic.php?f=7&t=267). I create a deb
package with make dkms_mkdeb. The resulting deb package actually has no
binaries inside but only source code and - what I assume are - some
instructions for DKMS (dkms.conf and some .c and .patch files) for
actually installing the deb package with dpkg.
Earlier in this thread, this was also discussed
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832558#20).
But then again the currently produced package works. So if no one else
complains, the behaviour may remain I guess (differentiating among
binary and non-binary packages just by name is probably not really needed).
Thanks again for fixing this bug.
Cheers
Hello,
I also think `dkms mkdeb' should produce a architecture independent
"_all.deb" package as long as content is source only.
My patch was taking "source-only" as de facto for mkdeb, because it
seemed to me to make sense with regard to the way I understand the usage
of dkms by Debian. However it does not match what the man page explains
and possibly breaks the way the command should act in some places.
As a result, keeping mkdeb possibly include the binary modules, hence
have an architecture dependent package (e.g. amd64.deb) seems safer.
That said however, running `dkms mkdeb' does not seem to include the
binary modules in my tests anyway, either with or without the
--binaries-only flag.
As a result, it seems to me that the mkdeb command is broken anyway ?
Question is: how should it be fixed ?
- should it actually include binaries unless source-only is set ?
or
- should it generate an arch independent _all.deb package (with man page
fixed accordingly) ?
All that explains why it was not easy to choose to report the fix
upstream or to just fix it in Debian, I guess.
Hope this helps
(Hope I got it right...)
Pierre
