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