[Development] Removing libudev dependency from binary packages?

Alejandro Exojo suy at badopi.org
Wed Oct 23 07:23:22 CEST 2013


El Martes, 22 de octubre de 2013, Knoll Lars escribió:
> So much for Linux distributions keeping binary compatibility.

Isn't exactly the same situation as with Qt? When the "next version of Qt 4.8" 
breaks binary compatibility, libqt5 is introduced. You link against either one 
or the other, and generally, both could be available for you to choose.

I'm surprised that libudev0 is not there, though. I suppose all applications 
that used libudev0 are ported to the new one.

> Not
> providing the package means you break every 3rd party app that needs
> libudev and doesn't come as part of the package management.

Which is the point of the package system of all distributions, isn't it? And I 
might add that is such a good idea that Microsoft and Apple also introduced 
similar concepts in their (desktop) systems.

Let me add a bit of constructive criticism:

I've been a fan of the installer framework and the Qt SDK. I understand that 
is not going away for a variety of reasons, and that in some use cases is the 
best approach to having a binary installer of Qt, Creator, etc. But after 
using it a lot, I've found the several issues:

- Recommended it to coworkers, and they installed it under the suggested 
directory ($HOME/Qt, if I recall correctly). Is the preferred place anyway 
since you don't have permissions to install in the root of the FS. Then 
another person wants to use the SDK in the same computer as well (but with a 
different account), so uninstall it, create some world-writable directory, and 
run the installer, this time pointing it to /opt/Qt. Now the other users are 
able to see the binaries and run them, but they don't have the shortcuts! 
Let's copy the files under ~/.config and ~/.local from one user to the other. 
Done (finally).

- After the nice experience of having the latest Qt available for development, 
I realize is not going to be so easy to put it in the target machine, since it 
is headless (yes, the app is QtCore/Network only), and I can't run the 
installer there. I ended copying the files from my PC, but I had to tweak 
LD_LIBRARY_PATH since the RPATH pointing to the developer's HOME is not very 
useful. :)


After this, my opinion is that the preferred way to go should be to think more 
in native package system for Linux. For example, Clang is shipping nightly 
builds through the package system: http://llvm.org/apt/ (ok, this are deb 
packages only, but the OBS provides several types of binaries for many 
distributions)

I don't know if it should be done downstream, or as additional binaries to 
what distributions offer. All I can say is that in the next months I'm going to 
need binaries of Qt 5.2 that work on Debian stable. Since that's not going to 
be provided by official repositories, I would prefer if the work is not wasted 
just for my own use case, so I will knock doors to see if somebody else is 
interested, or I can share the work with Debian packagers.

Thank you.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net



More information about the Development mailing list