On Tue, May 22, 2018 at 11:01:00AM -0500, Alberto Leiva wrote:
> } } So I have ended up with a means to create two packages; one for the
> } } modules and one for the clients.
> }
> } Should be easy to combine them into one package.
Should be easy to combine them into one source package.
> } The debian/control should contain just one binary package.
I doubt that
> > The debian/rules should install all the files into debian/<foopkg>.
>
> I haven't managed to pull this off yet (I haven't really tried much,
> mind you, because I've struggled patching a few other cracks), but I'm
> wondering now if attempting this is really a good idea.
>
> For one thing, `man dh_dkms` has this clause:
>
> IMPORTANT: binary packages using dh_dkms must have a name that
> ends in '-dkms'.
>
> Wouldn't be a little odd to have a .deb suffixed "-dkms" and have it
> carry binaries other than DKMS-packaged stuff?
foopkg-dkms_VER_ARCH.deb and foopkg_VER_ARCH.deb
> Second, I've been navigating through packages.debian.org for a while,
> and other projects always seem to upload kernel modules and utilities
> in separate packages.
As you said:
} } } So I have ended up with a means to create two packages; one for the
} } } modules and one for the clients.
Keep following the path of two packages (at least for now)
> Third, what would be the architecture of this package? "all" or "any"?
> The kernel modules are "all" (because they are just a bunch of files
> that get compiled on every new kernel), but the utils are "any"
> (because they are compiled C).
Source not yet seen, so suggesting 'any' to get to project forward.
> Should I not be attempting this in the first place?
Yes you "should". Every good work of software starts by scratching a
developer's personal itch.
( is from
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s02.html
)
Groeten
Geert Stappers
--
Leven en laten leven
