I was in a hurry when I read these messages, but today I finally absorbed what you're saying.

The i2c-dev module is fundamental to getting ddcutil and libddcutil working. The ddcutil Installation help page concerning kernel modules states "Kernel module i2c-dev must be loaded. On some distributions, it is built into the Linux kernel. If not, it must be loaded explicitly.". ( https://www.ddcutil.com/kernel_module/ )

So both of ddcutil and libddcutil require i2c-dev.

Furthermore, access for non-root users will require either appropriate group-membership or an appropriate udev rule. OpenSUSE has a package ddcutil-i2c-udev-rules-1.4.1-2.4.noarch.

Somewhat unexpectedly, ddcutil-i2c-udev-rules requires libddcutil4. I would have thought it should be the other way around.

I would also expect ddcutil to require ddcutil-i2c-udev-rules. It cannot pull this dependency in indirectly via libddcutil because Ddcutil does not require libddcutil, I think ddcutil is built or coded as a separate stand alone implementation (I believe ddcutil predates the development of the libddcutil, plus I've encountered bugs in libddcutil that don't occur with the ddcutil command).

I would also expect ddcui, a GUI for which libddcutil was created, to also directly or indirectly require ddcutil-i2c-udev-rules.

In fact, nothing requires ddcutil-i2c-udev-rules-1.4.1-2.4.noarch. That may be because it's a recent addition - I suggested using udev rules to the author of ddcutil a while back.

I don't think it's ddcutil-service's responsibility to pull in the fundamentals needed for libddcutil.

Again, loading the i2c-dev module is fundamental for ddcutil-service, not libddcutil.

That's why libddcutil cannot take care of that requirement for ddcutil-service.

Adding runtime requirement to libddcutil4 is bogus, that should be generated automatically when linking to it.

Here is my interpretation of what I think you might be saying:

Although it's libddcutil that actually uses i2c-dev, it's only when a program uses libddutil that an actual runtime requirement for i2c-dev is manifested. As long as libddcutil is only installed and not used, it has no need for i2c-dev to be loaded. In general the responsibility for ensuring i2c-dev is load should fall on all programs that intend to actually use the library.

Ddcui is another program that uses libddcutil to access i2c-dev, I guess installing it should also do something to get i2c-dev loaded. Plus the command line tool ddcutil uses i2c-dev directly, so installing ddcutil should also do something to get i2c-dev loaded. I don't think either includes anything in the rpm spec to do so. I think the documentation for those programs leaves getting i2c-dev loaded as something the user needs to do manually. I guess you're saying this not an acceptable approach.

So am I correct in interpreting what you are saying?

If so, several programs need i2c-dev, should there be a common package that they can require?

(I see what you mean about adding requires-libddutil - rpm build figures this out automatically.)

It's more subtle than that. libddcutil always needs i2c-dev to really do something useful.

However, not every time libddcutil is installed it is intended to be used.

There are times when a program is built against libddcutil but there is no intent to use it.

There are programs that operate on a number of different devices, and libddcutil of one of multiple hardware-specific libraries they might use.

If ddcutil-service was running as root it could load the module.

It does not. Still the package can at least install a module-load.d file to load the module on next boot.

The service itself can also report and error when the module is not loaded.

Both of this is demonstrated in the SR.

Thanks for the detailed explanations.

We're now assuming if the ddcuitl-service is installed, there is an intent to use it. This is a fair bet, because this particular service isn't installed by default.

I see you've now allowed for the variaos packages that use i2c-dev to have their own conf file in /etc/modules-load.d/. Thanks.

I'll fold in all the changes.

I will revisit the mod_probe check. I will most likely change the C code to produce meaningful errors if the module isn't present or permissions are lacking. The service will always start, even if only to return detailed errors to the clients. The clients can present the errors to the end-user. I'm trying to avoid the user having to any detective work to find out why the service isn't working.

As well as adding /usr/lib/modules-load.d/ddcutil-service.conf, I'm also going to add a %post to the ddcutil-service.spec that does a modprobe i2c-dev. That should hopefully ensure the service works immediately after installation without the user having to use sudo or reboot. Plus it should ensure an install error if i2c-dev isn't available.

I've added a runtime requirement of libddcutil4, I think that drags in everything needed.