-
Notifications
You must be signed in to change notification settings - Fork 152
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dkms_common.postinst: Add "Tuxedo" distributor id #257
base: master
Are you sure you want to change the base?
Conversation
I'm a Debian/Ubuntu noob, so perhaps a silly question: Why don't we use Nit: please prefix the commit with the file that's changed - |
Signed-off-by: Werner Sembach <[email protected]>
c2a749f
to
564c605
Compare
the /etc/lsb_release also exists on Ubuntu, and is parsed directly in another part in DKMS. There however not only the ID but also the ID_LIKE variable is checked, that's why it is no problem.
Done |
The official lsb_release (I believe) does not check At a glance Debian has their own minimal version for some reasons. So instead of depending on the fork/variant, it will be better to use |
Ubuntu is using this python based implementation of the lsb_release command: https://salsa.debian.org/debian/lsb by using os-release directly do you mean manually parsing /usr/lib/os-release? |
Ok reading the manual https://www.freedesktop.org/software/systemd/man/os-release.html standard is to only check /etc/os-release (which may or may not be a symlink to /usr/lib/os-release), and only if it doesn't exists checking /usr/lib/os-release. The python implementation of lsb_release I linked (and ubuntu is using) is violating that as it acesses /usr/lib/os-release directly. |
Maybe a better proposal, unifing the loggic in dkms a little bit: #270 |
Looking at the details: we're overriding the ARCH field, which seems to be a non-issue. Namely it is used effectively as a Code was added to fix https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/497149, but admittedly I don't grasp Debian/Ubuntu enough to judge if this is a genuine issue/fix. @anbe42 (feel free to tag other Debian devs) in your experience, have you ever seen similar patch for dkms in Debian? Does the issue sound something relevant to Debian - aka should we also add you lot in the "amd64" -> "x86_64" mapping, alternatively does it look like something which should be dropped? |
I've proposed removing the common.postinst script with #339. If you think that may cause issue please reply in there. If we end up removing it, this MR will no longer be needed. |
TUXEDO OS 1 is based on Ubuntu but modifies /usr/lib/os-release. DKMS however should do the same things as on Ubuntu. In most places this can be archived by the ID_LIKE field, however in the common postinstall script, not the ID_LIKE field is checked, but the ID field.
This patch adds the Tuxedo ID to the one if-case where it is relevant.
Signed-off-by: Werner Sembach [email protected]