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 -- Sebastian Ramacher