Bug#1032614: ddcutil: pre-approval request ddcutil-1.4.2-1 fixes bug #1031259
On 3/13/23 07:42, Sebastian Ramacher wrote: On 2023-03-13 07:25:41 -0400, Sanford Rockowitz wrote: On 3/13/23 05:33, Sebastian Ramacher wrote: On 2023-03-11 07:51:16 -0500, Sanford Rockowitz wrote: [Reason ] (Explain what the reason for the unblock request is.) As noted, the unblock request addresses bug #1031259. ddcutil requires driver i2c-dev. If it happens not to be built into the kernel, this entails post-installation system configuration. Despite extensive documentation and application warnings if the driver is not loaded, this can be challenging for inexperienced users. [ Impact ] (What is the impact for the user if the unblock isn't granted?) Manual post installation configuration will continue to be required as previously. [ Tests ] (What automated or manual tests cover the affected code?) None [ Risks ] (Discussion of the risks involved. E.g. code is trivial or complex, key package vs leaf package, alternatives available.) The changes are trivial, ensuring that driver i2c-dev is loaded if it is not already built into the kernel. Package libddccontrol0, an alternative to ddcutil for monitor control, installs file ddccontrol-i2c-dev.conf, which loads i2c-dev. The contents of that file, a single line containing "i2c-dev", is identical to the contents of the files to be installed by ddcutil. Additional examples of packages that install files in /user/lib/modules-load.d are fwupd, which installs file fwupd-msc.conf, and encryptfs-utils, which installs file ecryptfs.conf. The prpoposed changes also introduce a policy violation: /usr/lib/modules-load.d/libddcutil.conf installed in libddcutil4 is not versioned the same way as the shared library. See section 8.2 for more details. Cheers If the installed conf file were incorrect, the only effect would be an error in the system log, and manual user configuration would still be required as before. The only (potential) known dependency within Debian is from KDE PowerDevil. However, PowerDevil, as installed by Debian, is built with use of libddcutil if-tested out. (Recommended since its use of libddcutil is "proof of concept" level code.) [ Checklist ] [x] all changes are documented in the d/changelog [x ] I reviewed all changes and I approve them [x ] attach debdiff against the package in testing [ Other info ] (Anything else the release team should know.) As I read section 8.2, there are two possibilities. The first is to version the name of the file installed in /usr/lib/modules-load.d, e.g. libddcutil4.conf for package libddcutil4. The second is to create an additional package, named e.g. libddcutil-aux, that installs libddcutil.conf and on which package libddcutil4 and successor packages libddcutilN depend. The former has the advantage that it doesn't introduce an additional package simply to install a single file, and the disadvantage that it relies on a naming convention for the installed libddcutilN.conf file, which could easily be overlooked when bumping the SONAME. As we're in hard freeze, option 2 is not an option for bookworm. A third alternative is to not install a modules-load.d conf file for libddcutil, and instead rely on packages using the shared library to install a conf file. But that would multiply the number of packages installing files in modules-load.d, and the potential for errors. That doesn't really sound like a solution to the bug. It would leak implementation details of libddcutil to all the reverse dependencies. Cheers Setting aside what's possible given the bookworm freeze, do you have a strong opinion as to whether the naming convention or separate package is preferable/acceptable? I don't feel strongly that the update has to go into bookworm. I wanted to address the "bug report" promptly, but the change is more of an enhancement. Nothing is really actually broken, it's just that a post installation step is necessary for some users, which it would be kind to avoid.
Bug#1032614: ddcutil: pre-approval request ddcutil-1.4.2-1 fixes bug #1031259
On 3/13/23 05:33, Sebastian Ramacher wrote: On 2023-03-11 07:51:16 -0500, Sanford Rockowitz wrote: [Reason ] (Explain what the reason for the unblock request is.) As noted, the unblock request addresses bug #1031259. ddcutil requires driver i2c-dev. If it happens not to be built into the kernel, this entails post-installation system configuration. Despite extensive documentation and application warnings if the driver is not loaded, this can be challenging for inexperienced users. [ Impact ] (What is the impact for the user if the unblock isn't granted?) Manual post installation configuration will continue to be required as previously. [ Tests ] (What automated or manual tests cover the affected code?) None [ Risks ] (Discussion of the risks involved. E.g. code is trivial or complex, key package vs leaf package, alternatives available.) The changes are trivial, ensuring that driver i2c-dev is loaded if it is not already built into the kernel. Package libddccontrol0, an alternative to ddcutil for monitor control, installs file ddccontrol-i2c-dev.conf, which loads i2c-dev. The contents of that file, a single line containing "i2c-dev", is identical to the contents of the files to be installed by ddcutil. Additional examples of packages that install files in /user/lib/modules-load.d are fwupd, which installs file fwupd-msc.conf, and encryptfs-utils, which installs file ecryptfs.conf. The prpoposed changes also introduce a policy violation: /usr/lib/modules-load.d/libddcutil.conf installed in libddcutil4 is not versioned the same way as the shared library. See section 8.2 for more details. Cheers If the installed conf file were incorrect, the only effect would be an error in the system log, and manual user configuration would still be required as before. The only (potential) known dependency within Debian is from KDE PowerDevil. However, PowerDevil, as installed by Debian, is built with use of libddcutil if-tested out. (Recommended since its use of libddcutil is "proof of concept" level code.) [ Checklist ] [x] all changes are documented in the d/changelog [x ] I reviewed all changes and I approve them [x ] attach debdiff against the package in testing [ Other info ] (Anything else the release team should know.) As I read section 8.2, there are two possibilities. The first is to version the name of the file installed in /usr/lib/modules-load.d, e.g. libddcutil4.conf for package libddcutil4. The second is to create an additional package, named e.g. libddcutil-aux, that installs libddcutil.conf and on which package libddcutil4 and successor packages libddcutilN depend. The former has the advantage that it doesn't introduce an additional package simply to install a single file, and the disadvantage that it relies on a naming convention for the installed libddcutilN.conf file, which could easily be overlooked when bumping the SONAME. A third alternative is to not install a modules-load.d conf file for libddcutil, and instead rely on packages using the shared library to install a conf file. But that would multiply the number of packages installing files in modules-load.d, and the potential for errors. Is one alternative clearly preferable to the others from the Debian perspective? Thank you. Whether or not this change makes it into bookworm, the review process has been helpful.
Bug#1032614: ddcutil: pre-approval request ddcutil-1.4.2-1 fixes bug #1031259
[Reason ] (Explain what the reason for the unblock request is.) As noted, the unblock request addresses bug #1031259. ddcutil requires driver i2c-dev. If it happens not to be built into the kernel, this entails post-installation system configuration. Despite extensive documentation and application warnings if the driver is not loaded, this can be challenging for inexperienced users. [ Impact ] (What is the impact for the user if the unblock isn't granted?) Manual post installation configuration will continue to be required as previously. [ Tests ] (What automated or manual tests cover the affected code?) None [ Risks ] (Discussion of the risks involved. E.g. code is trivial or complex, key package vs leaf package, alternatives available.) The changes are trivial, ensuring that driver i2c-dev is loaded if it is not already built into the kernel. Package libddccontrol0, an alternative to ddcutil for monitor control, installs file ddccontrol-i2c-dev.conf, which loads i2c-dev. The contents of that file, a single line containing "i2c-dev", is identical to the contents of the files to be installed by ddcutil. Additional examples of packages that install files in /user/lib/modules-load.d are fwupd, which installs file fwupd-msc.conf, and encryptfs-utils, which installs file ecryptfs.conf. If the installed conf file were incorrect, the only effect would be an error in the system log, and manual user configuration would still be required as before. The only (potential) known dependency within Debian is from KDE PowerDevil. However, PowerDevil, as installed by Debian, is built with use of libddcutil if-tested out. (Recommended since its use of libddcutil is "proof of concept" level code.) [ Checklist ] [x] all changes are documented in the d/changelog [x ] I reviewed all changes and I approve them [x ] attach debdiff against the package in testing [ Other info ] (Anything else the release team should know.)
