My apologies, but i do not see anything out of the ordinary here i mean... there are programs out there which are building
1. A .so shared library
2. A .a static library
3. An executable as 'example' . Those are link against the .a.
On Sat, Jan 25, 2020 at 11:13 PM Sanford Rockowitz wrote:
What's unusual is that the command line version does not depend on the
shared library. Both versions are built from the same source package
...
Is this design just atypical, or does it violate Debian practice in some
way?
It is hard to say without reviewing a lot libraries, but think the
practices of different upstreams vary widely, some tools solely wrap
shared libraries, some have an additional "private" shared library,
some use your approach.
I don't think it violates any Debian practice that I can think of.
One downside in the case of ddcutil is that the command-line tools
will have a different set of capabilities to any tools built on the
shared library (GUIs etc).
BTW, are you aware of any effort to support DDC in the Linux kernel?
It would be useful to be able to control monitor brightness etc from
standard graphical interfaces that can currently only control laptop
screen brightness.
--
bye,
pabs