[Development] Removing libudev dependency from binary packages?

[Laszlo Papp]

Having realized after some work that QtWebKit is now trying to achieve more
or less the same as QtSerialPort ... how about about the udev resolver to
QtCore now as a private stuff ... like qtlibudev_p.h or similar kind.
Afterwards, QtWebKit could use core-private, so could QtSerialPort. We
would also have to import it into our qt4support folder for sure...

This could then be refactored:

https://codereview.qt-project.org/#change,69202

Just like this:

https://codereview.qt-project.org/#change,69178

Cheers ...

On Thu, Oct 24, 2013 at 11:03 PM, Laszlo Papp <lpapp at kde.org> wrote:

> Actually having thought a bit about this, and written the change more or
> less, my personal opinion is that it would be better to get distribution
> packages (via OBS or any other kind) correctly in the future...
>
> udev, and probably other libraries might not guarantee binary
> compatibility for releases, and it may happen that they bump the version
> frequently in which case it would hard to do cross-working software.
>
> Strictly speaking, dynamic library management even complicates the code
> for everyone having to deal with udev, or some other similarly determined
> libraries.
>
> If Qt can make sure in the future there are proper distribution packages
> (at least for the common variants), this would not be such a big issue. I
> understand it cannot happen any soon. I am personally fine with building
> QtSerialPort for 5.2 without udev for the official installer. Archlinux,
> and some other distribution users will get it right from the distribution
> packagers after all.
>
> Well, this is my two cents.
>
>
> On Thu, Oct 24, 2013 at 9:13 PM, Laszlo Papp <lpapp at kde.org> wrote:
>
>> https://bugreports.qt-project.org/browse/QTBUG-34329
>>
>>
>> On Thu, Oct 24, 2013 at 4:36 PM, Knoll Lars <Lars.Knoll at digia.com> wrote:
>>
>>> Sounds like dlopen¹ing is the way to go. Sucky, but at least it¹ll work.
>>> And according to the post below most things should be compatible between
>>> udev0 and udev1.
>>>
>>> Cheers,
>>> Lars
>>>
>>> On 24/10/13 16:28, "Thiago Macieira" <thiago.macieira at intel.com> wrote:
>>>
>>> >On quinta-feira, 24 de outubro de 2013 13:46:39, Koehne Kai wrote:
>>> >> I just asked, it seems not to be possible:
>>> >>
>>> >>
>>> http://www.marshut.com/yiqmk/can-apps-ship-their-own-copy-of-libudev.html
>>> >>
>>> >>
>>> >> So we're back to either moving the libudev dependency to a plugin that
>>> >> qtserialport tries to load (huh), we live with the fact that
>>> >>qtserialport
>>> >> won't work on some distributions, or we compile it unconditionally
>>> >>without
>>> >> libudev support. I don't mind either way ...
>>> >
>>> >Ok, thanks Kai
>>> >
>>> >That answers the part about shipping (static or dynamic). So the only
>>> >option
>>> >is dynamic loading (ugh) or skipping support entirely (also ugh).
>>> >
>>> >PS: None of the systemd developers were in my binary compatibility
>>> >session
>>> >yesterday here at LinuxCon.
>>> >
>>> >PPS: http://www.youtube.com/watch?v=jjRAKuis7T8 @ 16:55
>>> >"people have heard my complaints about the fact that the Linux desktop
>>> is
>>> >this
>>> >morass of infighting and people who do bad things"
>>> >"I do hope that the desktop people would just try to work together and
>>> >work
>>> >more on the technology"
>>> >Linus started complaining about the problems on the userspace *because*
>>> >of
>>> >udev. See https://lkml.org/lkml/2012/10/2/303.
>>> >
>>> >--
>>> >Thiago Macieira - thiago.macieira (AT) intel.com
>>> >  Software Architect - Intel Open Source Technology Center
>>> >_______________________________________________
>>> >Development mailing list
>>> >Development at qt-project.org
>>> >http://lists.qt-project.org/mailman/listinfo/development
>>>
>>> _______________________________________________
>>> Development mailing list
>>> Development at qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/development
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20131025/0242bac3/attachment.html>