Both are merely symlinks to libudev.so which is the main library and should contain the same library functionality as version 0. Try this, install eudev and create the symlinks from libudev.so to .1 and .0 equally and test the build against things using .0 and things using .1 independently. I haven't had any problems so far myself, and I've been using eudev for many months now.

1 members found this post helpful.

Let's go back on topic now, please.

Yuck. It works for your use case by chance. They are not binary compatible because some functions in udev changed their return value at the so bump, and some were removed (this is apart from the API additions, which do not break ABI). Otherwise there would not have been an so bump in the first place.

As I understand it eudev is something of a hybrid. I think it keeps the libudev.so.0 ABI but adds hwdb support.

The question of which version of udev to ship is on topic.

PV certainly won't listen to the clamor of the crowd to decide that. Furthermore this has been already discussed ad nauseam, so no need to beat a dead horse.

Seeing that eudev has stabilized, the issue of the hardware database is fickle at best. To be honest, udev-classic and eudev+gudev literally are identical in function minus a few modernizations including some fixes to the code to handle rules more efficiently, some bug fixes, and other new things to handle the system, plus eudev is reworked to be more compatible with sysvinit and OpenRC setups.

However, let me reiterate this... Slackware works fine with either regardless of using eudev or udev-classic, (even Robby had udev extracted from systemd working) though with OpenRC from SBo, eudev might work a bit better as the scripts are more aimed at eudev, but will work fine with udev-classic. Slackware's bsd-style rc scripts are scripted for either.

1 members found this post helpful.

Chill a little. The question was asked what further additions were wanted for the next release, and I answered. I do not think that the question of udev (as opposed to systemd) has been discussed ad nauseam. I think you are making too much of it.

1 members found this post helpful.

Any thoughts on upgrading texinfo as per post #158?

A new cairo release 1.14.4 is now available from:

http://cairographics.org/news/cairo-1.14.4/

http://cairographics.org/releases/cairo-1.14.4.tar.xz

it work here:

maybe update 'gcr-3.18.0' for alignement on gnome-3.18, just (translation update)

Awesome! What could possibly go wrong?

If I was Santa, I'd be scared of those last two sentences, but I'm not Santa.

Maybe being too terse my statement was perceived as harsh, then I am sorry: this was not intentional.

I will elaborate a bit:

1. You are right that udev has been less discussed than systemd in this forum. Fortunately. Still, it has been already discussed, for instance here and there.
2. As you well know, udev is not a stand-alone component that one could just "plug-in" without any consequences on the rest of the system. This is a major sub-system thus changing the version is something that needs much care to make sure everything else continues to work as expected. But I am sure that the Slackware team is aware of the available options and the benefits and risks associated to an update, so I am confident that a sane decision will be taken.
3. This notwithstanding you are of course still free to request an update of udev. But I assume that for such a request to be considered it should include some precisions beyond a (rather vague, IMHO) statement like " Some proprietary stuff expects to link against libudev.so.1 and some non-proprietory code expects some of the new functions available with that so bump."

Last week Greg Kroah-Hartman revealed that kernel 4.4 will be a LTS (Long Term Support) one.

http://linux.softpedia.com/blog/linu...e-495450.shtml

https://plus.google.com/+gregkroahha...ts/WMEWz4noxFm

Can there be a test kernel configuration for 4.4 if we don't go to that as the main kernel?

2 members found this post helpful.

If it is LTS, then highly possible.

If not already in the pipe, I'd like to point the radar to this major release.

It introduces a new ABI, so I realize that before shipping it the many applications that depend on it will need to be checked as still working and possibly rebuilt. But using the new ABI brings new features like 256 colors, allow using a wheel mouse on xterm and similar, more terminal descriptions including tmux and mlterm3, support of wide characters. But the old ABI can still be used.

What it still lacks IMHO is bidi capability through optional usage of the fribidi library (a request triggered this answer: "it's something to explore (I'll add a to-do item)"). I imagine that Thomas E. Dickey's to-do list is already very long

Anyhow I am grateful to him for the TLC he continues to give to ncurses, dialog, lynx and xterm to name some.

PS dialog could be upgraded as well on the occasion.

1 members found this post helpful.