hello,
diverging from upstream makes no sense to me, since the mkdeb approach has been
introduced by us...what about discussing this with them and find a common
approach?
I'm not a direct user of this tool, so I can't have an opinion :)
G.
Il lunedì 14 gennaio 2019, 13:21:58 CET, Pierre Neyron
<pierre.ney...@free.fr> ha scritto:
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
>
