kmp packages on openSUSE #2
Labels
Comments
|
I'm not at all familiar with KMP packages and I doubt it'll make much over an improvement over dkms? |
|
advantage is that the drivers are already compiled and your package doesnt have to require dev tools during installation. |
|
one example for a KMP package https://build.opensuse.org/package/show/network:vpn:wireguard/wireguard |
|
Feel free to submit a PR but I'm not interested in implementing this personally. |
darix
added a commit
to darix/OBS-packaging
that referenced
this issue
Aug 15, 2021
A while ago i promised a KMP port for openSUSE so we do not need build
tools on the user machines.
While I did this i did some cleanup to the spec file
A more readable diff might be:
diff -urwN {hardware:razer,home:darix:playground}/openrazer/openrazer.spec
1. renaming main package to openrazer because the kmp packages are named -kmp
and the main packag needs to be an arch specific package so the kmp
macros work. So I move the meta package to a subpackage and marked the
subpackage noarch. The 2 python packages are marked noarch for the same
reason now.
2. which handling of the kernel module is being used is decided with the
conditional on top. to keep the configuration in one place, I also
defined a variable in the same place for the driver package
so if you want to build a dkms version for opensuse:
`osc build --without=openrazer_kmp openSUSE_Tumbleweed`
In theory you could do a kmp build on non opensuse distros but this should just fail.
3. moved the udev rules and related handling to the daemon subpackage
I think it makes more sense to have that here or can there be a valid
use case where you want the driver but not at least the openrazer-daemon?
If there is such an use case then we should probably move the udev
rules + user handling into a subpackage like openrazer-udev so that
the dkms and kmp can Requires it.
4. generic cleanup
1. BuildRequires can work in subpackages but it is usually preferred
to have them all on the main package
2. only run the the dkms test build if we are not in the OBS build
env. Or do you prefer having it run all the time to make sure it
works? I also fixed the requires for the dkms/make package and
added a longer comment on why they are needed
3. more consistent indenting in the preambles
This fixes issues openrazer#2
darix
added a commit
to darix/OBS-packaging
that referenced
this issue
Aug 15, 2021
A while ago i promised a KMP port for openSUSE so we do not need build
tools on the user machines.
While I did this i did some cleanup to the spec file
A more readable diff might be:
diff -urwN {hardware:razer,home:darix:playground}/openrazer/openrazer.spec
1. renaming main package to openrazer because the kmp packages are named
<name of main package>-kmp and the main package needs to be an arch
specific package so the kmp macros work. So I move the meta package to
a subpackage and marked the subpackage noarch. The 2 python packages are
marked noarch for the same reason now.
2. which handling of the kernel module is being used is decided with the
conditional on top. to keep the configuration in one place, I also
defined a variable in the same place for the driver package
so if you want to build a dkms version for opensuse:
`osc build --without=openrazer_kmp openSUSE_Tumbleweed`
In theory you could do a kmp build on non opensuse distros but this
should just fail.
3. moved the udev rules and related handling to the daemon subpackage
I think it makes more sense to have that here or can there be a valid
use case where you want the driver but not at least the openrazer-daemon?
If there is such an use case then we should probably move the udev
rules + user handling into a subpackage like openrazer-udev so that
the dkms and kmp can Requires it.
4. generic cleanup
1. BuildRequires can work in subpackages but it is usually preferred
to have them all on the main package
2. only run the the dkms test build if we are not in the OBS build
env. Or do you prefer having it run all the time to make sure it
works? I also fixed the requires for the dkms/make package and
added a longer comment on why they are needed
3. more consistent indenting in the preambles
This fixes issues openrazer#2
darix
added a commit
to darix/OBS-packaging
that referenced
this issue
Aug 16, 2021
A while ago i promised a KMP port for openSUSE so we do not need build
tools on the user machines.
While I did this i did some cleanup to the spec file
A more readable diff might be:
diff -urwN {hardware:razer,home:darix:playground}/openrazer/openrazer.spec
1. renaming main package to openrazer because the kmp packages are named
name_of_main_package-kmp and the main package needs to be an arch
specific package so the kmp macros work. So I move the meta package to
a subpackage and marked the subpackage noarch. The 2 python packages are
marked noarch for the same reason now.
2. which handling of the kernel module is being used is decided with the
conditional on top. to keep the configuration in one place, I also
defined a variable in the same place for the driver package
so if you want to build a dkms version for opensuse:
`osc build --without=openrazer_kmp openSUSE_Tumbleweed`
In theory you could do a kmp build on non opensuse distros but this
should just fail.
3. moved the udev rules and related handling to the daemon subpackage
I think it makes more sense to have that here or can there be a valid
use case where you want the driver but not at least the openrazer-daemon?
If there is such an use case then we should probably move the udev
rules + user handling into a subpackage like openrazer-udev so that
the dkms and kmp can Requires it.
4. generic cleanup
1. BuildRequires can work in subpackages but it is usually preferred
to have them all on the main package
2. only run the the dkms test build if we are not in the OBS build
env. Or do you prefer having it run all the time to make sure it
works? I also fixed the requires for the dkms/make package and
added a longer comment on why they are needed
3. more consistent indenting in the preambles
This fixes issues openrazer#2
|
any more questions about this submission? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
instead of building the modules on the user machine via dkms, can we not just do kmp packages?
The text was updated successfully, but these errors were encountered: