Bug#1032614: ddcutil: pre-approval request ddcutil-1.4.2-1 fixes bug #1031259
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
Reply to: