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.
