eudev-1.7

[Fernando de Oliveira]

​http://dev.gentoo.org/~blueness/eudev/eudev-1.7.tar.gz

[bdubbs@…]

Hold this until LFS is updated.

[bdubbs@…]

LFS has been updated so this can now go into BLFS.

[Pierre Labastie]

Never done this one before. I may need help...

[Pierre Labastie]

To test upgrading, I have built LFS SVN-20140527 (with eudev-1.6), on a virtual machine with an LVM disk. Had some difficulties with the initramfs (udevd is back to /sbin...) The upgraded to eudev-1.7 Everything seems to run smoothly, but I do not have much (virtual) harware (one NIC, one graphic card). All in all, I left the title as it was, but kept the version in the tarball name, adding a note about upgrading.

[Pierre Labastie]

Fixed at r13214

[Fernando de Oliveira]

Thanks for the update.

The problem is that the objective of the page is not to install eudev, but to add new features to the installed one, needed for some BLFS packages and which could not be included in LFS, due to the lack of dependencies. This was pointed out to you by Bruce, who also agreed with me about the difference betwenn LFS (installed) and BLFS (eventually newer) eudev versions.

Replying to pierre.labastie:

To test upgrading, I have built LFS SVN-20140527 (with eudev-1.6), on a virtual machine with an LVM disk. Had some difficulties with the initramfs (udevd is back to /sbin...) The upgraded to eudev-1.7

So, you built a vm just for this upgrade.

Everything seems to run smoothly, but I do not have much (virtual) harware (one NIC, one graphic card).

In the past, before systemd broke udev, I used to upgrade udev (I think you can find it in the archives, some dev wrote I was "very courageous" or something like that). Only once had a problem, IIRC. For the book, due to the responsibility, I did not want to do what once and, after your note, still today was not supposed to be done.

Not being a page for installing a package, but having a page to update is just a waist of time, already spent in LFS.

Also, I do not want to have the responsibility to eventually induce a breakage in a user system.

All in all, I left the title as it was, but kept the version in the tarball name, adding a note about upgrading.

Adding one note about potential problems is another demonstration that the book's page should be reversed to the old style.

One question you posed was if anybody had done it before, and at least Bruce wrote that he didn't, and it was a response, although not direct.

I don't think that building a LFS just to update eudev is worth the trouble, and I certainly will never do it, and doubt any other developer but you would.

Therefore, I will reverse the page to the old style,

Thanks, anyway.

[Pierre Labastie]

Please Fernando, do not do that (revert to old style) before asking Bruce. This is his layout, not mine...

We do not agree. It does not give you the right to change the page. I may be wrong, but I have carefully read what is said on Gentoo (the eudev maintainers), and they warn about issues, yes, but all packages have potential issues when upgrading. Actually, give me a good reason to not upgrade, and I'll show you it may be applied to any new version of any new package. For example, the last update of giflib broke a lot of packages I have been fixing later (with Armin's and your help). I guess it should be the same for eudev.

I have also looked at how it could be possible to just install gudev without rebuilding everything, although I do not think it is worth it (0.3 SBU max): all I have thought of would make the instructions more complicated...

So, all in all, the page is usuable as it is.

As for what I build for testing and so on, it is my own business. I have done a lot of LFS building, because LFS has been pretty unstable these last months. This is just one more (automated with jhalfs, so not a big trouble). And my last build was becoming pretty old (a month or so) anyway.

[bdubbs@…]

I don't have a problem with someone doing an upgrade for eudev if they know the hazards. I really don't think replacing things like binaries or man pages would be a problem. Where I think problems might arise is in the configuration. That is, the rules may change. In that case, deleting all the rules in before upgrading could be appropriate.

I don't recall right now if some packages drop rules into /lib/udev/rules.d/ or not. If so, that would cause problems. It's also possible that custom rules in /etc/udev/rules.d/ could be affected.

My thought is that there should be a warning that upgrading should only be done if there is an expressed need that the user needs to be addressed, not just to update to the latest version.

We do have several versions that have been in the book on anduin:

​http://anduin.linuxfromscratch.org/sources/BLFS/conglomeration/eudev/
​http://anduin.linuxfromscratch.org/sources/BLFS/conglomeration/udev/
​http://anduin.linuxfromscratch.org/sources/LFS/lfs-packages/

And upstream has systemd:

​http://www.freedesktop.org/software/systemd/

for the case where we were extracting udev from systemd.

[Fernando de Oliveira]

Thanks, Bruce,

I will include the warning in the page, when I fix ticket #5154.