If you are interested in trying eudev as a drop-in replacement of udev in Slackware 14.1, see here: http://slint.fr/misc/eudev/ but please read the README first.

Please share your bug reports and constructive criticism.

However:

• This is just for fun, and possibly to give useful feedback to eudev maintainers as they want it to be init system agnostic (see the project's announcement here)
• IMO there is no point in suggesting or requesting, let alone demanding, that Pat replace udev with eudev in Slackware. He is aware of all the alternatives of systemd/udev and, case occurring will tell in a timely manner if, when and from who he needs help to test and evaluate them.
• Please refrain to make any comment about systemd or its developers in this thread. It's devoted to evaluation of eudev's usage in Slackware, period.

I draw your attention on one obvious change: the new hardware database index /etc/udev/hwdb.bin replaces the files stored in /lib/udev/keymaps, see udevadm hwdb [options] in (new) "man udevadm".

I guess that some Slackers won't be happy with the replacement of text files by a binary database, however all we need to know now and here is "does it work?".

Also, please tell me if you see something missing in the package that you build using the provided material.

PS the directory http://slint.fr/misc/eudev/ have been unaccessible during a few minutes due to an upload error, sorry for that.

PPS I see that some folks are downloading the files one by one using a browser. Better type:

Very nice. A good idea, this. I am a bit busy to mess with this just now, but when I get a chance, I will definitely give this a go.
Thanks!

Good work Didier! Excellent package.

I second that! A fine build like the french cuisine!

And, BTW, works like a charm.

Thanks for your encouragement, but praise Bob not Didier. I only adapted to eudev the awesome work done by Pat.

Also, there's certainly room for improvement in packaging and/or upstream work.

For instance I didn't actually check the new or updated rules shipped in the package, neither the hdwb database that replaces the keymaps (could someone owning relevant hardware do that?).

Also, it could be useful to be able to run update-pcids and update-usbids in the post-install script that would then update /etc/udev/hwdb.d/{20-pci-vendor-model.hwdb,20-usb-vendor-model.hwdb} accordingly *before* (re)building /etc/udev/hwdb.bin running "udevadm hwdb -update". Ok, that's probably too convoluted, not worthwhile and would need an Internet access during installation, but take it as an example.

I think we owe Didier a beer.

I'd prefer a glass of Romanée Conti if you can afford it, else orange juice, thanks

If you tested the package, what are your findings?

Works as a perfect drop in replacement on my testing. The current udev rules work the same. Very stable. I have Eudev 1.6 on B/LFS so by fair comparison, it works exactly the same and works as it's supposed to and seems to be fairly well behaved as far as rule handling goes.

Now if we could get Patrick to sign off on it as official...

I stand by what I wrote in the first post of this thread but as you insist let me elaborate why I think that this kind of request is futile.

Yes we can have a working system including eudev in Gentoo, Slackware, B/LFS (BTW, I've just read what you wrote here :-) and probably (to be released) Crux 1.3 at time of writing. So what?

Can we guarantee that the small team of Gentoo developers who (independently from the main Gentoo project) extract udev from systemd will be able to stay in sync with systemd's evolutions that *could* make this extraction harder or irrelevant in the future? Even then, can we guarantee that other major components of the system will continue to work, if eudev is used but not integrated with systemd?

There are many other issues that need to be addressed, have a look as this interesting thread.

I can't speak for Pat, but I assume that a distribution's maintainer has to address many other concerns than just "does it work here and now?" before deciding to ship a software.

Sorry, but you compressed your files.diff.gz with -z option.
Even after gzip -d the files.diff, if test them by:
# file rule*.diff
it says it's gzipped so I renamed both files*.diff --> files*.diff.gz
And the same for the eudev-1.6.tar.gz, gzip -d, and then gzip -9 on the package for the Slackbuild to work.
And after it compiled finely.

Nice work, otherwise.

Thanks Didier. I might have a play if I get the time but whether I do or not I'm glad you took the trouble to do this.

I'm a bit puzzled. I didn't use the -z option (that is not listed in "man gzip" here) and (still here) the zcat commands included in the SlackBuild works without issue, even though I didn't set the speed of compression. And after "gzip -d" the files are uncompressed as using zcat. Maybe something specific to your installation could explain that difference in behavior?

Thanks for the report anyhow.

PS shar has a "-z" option, but I used gzip.

My installation is a pure slackware-14.1 (x64) installation up to date:

that's what I get without modification of the files from http://slint.fr/misc/eudev/:

root@darkstar64:~/Downloads/eudev/new# ./eudev.SlackBuild
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Exiting with failure status due to previous errors

Then I did:
root@darkstar64:~/Downloads/eudev/new# gzip -d eudev-1.6.tar.gz
root@darkstar64:~/Downloads/eudev/new# file eudev-1.6.tar
eudev-1.6.tar: gzip compressed data, from Unix, last modified: Tue Apr 15 15:10:05 2014, max compression
root@darkstar64:~/Downloads/eudev/new# mv eudev-1.6.tar eudev-1.6.tar.gz

I re-run the Slackbuild:
root@darkstar64:~/Downloads/eudev/new# ./eudev.SlackBuild

Then I get the following message (just the last 4 lines):
-----
eudev-1.6/Makefile.am
eudev-1.6/config.sub
Hmm...patch unexpectedly ends in middle of line
I can't seem to find a patch in there anywhere.

Then with the patches, what I did:
root@darkstar64:~/Downloads/eudev/new# gzip -d *.diff.gz
root@darkstar64:~/Downloads/eudev/new# file *.diff
60-cdrom_id.rules.diff: gzip compressed data, was "60-cdrom_id.rules.diff", from Unix, last modified: Fri May 16 10:18:21 2014
rule_generator.diff: gzip compressed data, was "rule_generator.diff", from Unix, last modified: Fri May 16 10:17:14 2014
root@darkstar64:~/Downloads/eudev/new# gzip -d udev-fixed-devices.tar.gz
root@darkstar64:~/Downloads/eudev/new# file udev-fixed-devices.tar
udev-fixed-devices.tar: gzip compressed data, from Unix, last modified: Sat May 29 04:42:42 2010

So I renamed the diff's and the tar:
root@darkstar64:~/Downloads/eudev/new# mv 60-cdrom_id.rules.diff 60-cdrom_id.rules.diff.gz
root@darkstar64:~/Downloads/eudev/new# mv rule_generator.diff rule_generator.diff.gz
root@darkstar64:~/Downloads/eudev/new# mv udev-fixed-devices.tar udev-fixed-devices.tar.gz

I re-re-run the Slackbuild:
root@darkstar64:~/Downloads/eudev/new# ./eudev.SlackBuild

and I got (only the lines patching):

Hmm... Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- ./rule_generator/write_cd_rules 2014-04-15 14:57:09.000000000 +0200
|+++ ./rule_generator/write_cd_rules 2014-05-15 23:18:30.252753115 +0200
--------------------------
patching file rule_generator/write_cd_rules
Using Plan A...
Hunk #1 succeeded at 3.
Hunk #2 succeeded at 23.
Hunk #3 succeeded at 85.
Hunk #4 succeeded at 148.
done
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- ./rules/60-cdrom_id.rules.orig 2014-01-18 19:22:22.000000000 +0100
|+++ ./rules/60-cdrom_id.rules 2013-09-26 23:23:27.000000000 +0200
--------------------------
patching file rules/60-cdrom_id.rules
Using Plan A...
Hunk #1 succeeded at 15.
done
------------

And the last 4 lines of build:

ownership of './etc/udev/rules.d' retained as root:root
ownership of './etc/rc.d' retained as root:root
Creating Slackware package: /tmp/eudev-1.6-x86_64-1.txz


Slackware package /tmp/eudev-1.6-x86_64-1.txz created.

So?

So, I really don't know...

I couldn't reproduce your issue, downloading the files through lftp.

Also among the files I downloaded:

• eudev-1.6.tar.gz is nor corrupted according to the md5sum provided @ http://dev.gentoo.org/~blueness/eudev/
• udef-fixed-devices.tar.gz (that I didn't modify) is identical to the one found in udev source for Slackware64-14.1 according to zdiff.

So, sorry but no clue why this happens in your installation. I could change the compression level of the patches though I can hardly see why that would change something.

Is anybody else coming across the same issue?
And could you check that the files you downloaded are not corrupted?

I didn't use those patches in LFS. Are they absolutely necessary?