[Development] Removing libudev dependency from binary packages?

[Laszlo Papp]

On Tue, Oct 22, 2013 at 8:27 AM, Knoll Lars <Lars.Knoll at digia.com> wrote:

> On 22.10.13 09:24, "Thiago Macieira" <thiago.macieira at intel.com> wrote:
>
> >On terça-feira, 22 de outubro de 2013 07:01:22, Knoll Lars wrote:
> >> >There are two major versions of libudev in use in major distros:
> >> >libudev.so.0
> >> >and libudev.so.1. The new one has been in use for about a year, so we
> >>can
> >> >expect the need to support both versions for the next few years of
> >>builds.
> >>
> >> Isn't the old version still available on new distroibutions for
> >>backwards
> >> compatibility? In that case we could simply use the old version for the
> >> time being.
> >
> >No, not really. If a library isn't needed by anything else and there are
> >no
> >extraordinary reasons for keeping it (like it happens for the LSB
> >packages),
> >the library isn't provided at all.
> >
> >At least for Fedora 19, no package provides libudev.so.0. If I wanted to
> >install it, I'd have to load the package from Fedora 17.
>
> So much for Linux distributions keeping binary compatibility. Not
> providing the package means you break every 3rd party app that needs
> libudev and doesn't come as part of the package management.
>

As for QtSerialPort, in my opinion libudev is a fundamental part of it. I
personally think that is the only reliable way of getting serial port
information out of the system. Any other fallback option is just a "dirty
workaround" in my opinion. I am also not sure how strict this idea is for
add-ons.

Failing that, the "dirty workarounds" can guarantee fallback code paths
(hard coded device entry names and sysfs). It would not be that unusable,
but not completely reliable either in my opinion. If anything, removing the
udev package on the build machine for instance while packaging the release
would disable libudev in QtSerialPort. I do not think anything more
intrusive is worth it.

Laszlo

PS.: But yes, so much for Linux distributions keeping binary compatibility.
:/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20131022/6ed4168a/attachment.html>