Hello Gianfranco,
Ok, but what mkdeb patch would you like ?
a- should it actually include binaries unless source-only is set ?
or
b- should it generate an arch independent _all.deb package (with man
page fixed accordingly) ?
I'm more likely to volunteer for b, even if it makes Debian's dkms
diverge from upstream in the way mkdeb works...
Cheers
Pierre
On 14/01/2019 13:01, Gianfranco Costamagna wrote:
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 ?
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
