Hello,I'm happy to accept an eventual patch :) G. Il domenica 13 gennaio 2019, 17:10:39 CET, Pierre Neyron <pierre.ney...@free.fr> ha scritto: 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