On 2023-03-13 13:28:47 -0400, Sanford Rockowitz wrote: > 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.
An additional binary package for a file with one line is overkill, IMHO. Cheers -- Sebastian Ramacher
