So, the mess has finally come to pass. While this is filed as a version bump for systemd, it's actually meant for udev maintainers. How should this be split in Gentoo ?
I say: wait till they fix the build system. Or even better, provide patches for them.
To answer the question in comment #0: There will still be two ebuilds, one for udev and one for systemd. The upstream merge is not going to mean that our packages will merge.
Well, the question was more on the implementation side, cause it seemed pretty obvious, that - as things are now - it needs to be split.
This is being discussed and worked on on the linux-hotplug mailing list, so I am assigning it to udev-bugs. It will probably be udev-185 before I can add it to the tree. I am also dropping systemd from the bug, but feel free to add them back if you think they need to be there.
Well, this hits us as well so we're listen. It'd be good if systemd ebuild could also disable building udev.
Ok, udev-185 is out, and I could probably work on getting it into the tree, but if I do, it has a hard buildtime dependency on dbus and libcap. That means that every gentoo user will have to install these packages long enough to build udev. I am working with upstream, however, on getting rid of this requirement, so, what do you think? should we put newer udevs in the tree with that requirement?
(In reply to comment #6) > Ok, udev-185 is out, and I could probably work on getting it into the > tree, but if I do, it has a hard buildtime dependency on dbus and > libcap. That means that every gentoo user will have to install these > packages long enough to build udev. > > I am working with upstream, however, on getting rid of this requirement, > so, what do you think? should we put newer udevs in the tree with that > requirement? Maybe hard-masked. Could you attach the ebuild for reference? I guess it has more scary stuff than unnecessary build-time deps...
You are right, it is much more complex than just dealing with some extra build-time dependencies. Currently the build system builds the entire systemd tree then we have to remove the things we do not need from the image in src_install. I am working on their build system to come up with a way to only build udev.
All, for the short term, I want to put udev upgrades on hold until we can work out our differences with upstream [1]. At this point, I am optimistic, because I haven't heard from the developers yet. [1] http://lists.freedesktop.org/archives/systemd-devel/2012-June/005434.html
@comment 9: given the response on that list, I'd be *pessimistic*. ATM, you've heard only from systemd trolls, bashing source-based distros and the main devs stay suspiciously silent. Some of them seem to make a point of misunderstanding the issue.
(In reply to comment #10) > @comment 9: given the response on that list, I'd be *pessimistic*. > ATM, you've heard only from systemd trolls, bashing source-based distros and > the main devs stay suspiciously silent. > Some of them seem to make a point of misunderstanding the issue. Yes, you are right, but I think it is reasonable to give the devs a chance to respond.
Now I am working with flameeyes to come up with a smaller patch; then we will go directly to the developers.
For now, I've committed systemd-185 with blocker on udev. If anyone wants, feel free to test it. It has no Gentoo patches or files (which were in udev ebuild), and you need to put udev in package.provided to use it.
(In reply to comment #13) > For now, I've committed systemd-185 with blocker on udev. If anyone wants, > feel free to test it. It has no Gentoo patches or files (which were in udev > ebuild), and you need to put udev in package.provided to use it. systemd-185 with USE=gudev failed to compile on my system. May be should create a new issue?
(In reply to comment #14) > (In reply to comment #13) > > For now, I've committed systemd-185 with blocker on udev. If anyone wants, > > feel free to test it. It has no Gentoo patches or files (which were in udev > > ebuild), and you need to put udev in package.provided to use it. > > systemd-185 with USE=gudev failed to compile on my system. May be should > create a new issue? Feel free to. I expect to take a closer look at systemd udev part sometime soon.
> You need to put udev in package.provided to use it, and beware something will break, certainly. The biggest broken thing - is libudev.so.0 Systemd provides libudev.so.1 Upgrade should be done very carefully.
(In reply to comment #16) > > You need to put udev in package.provided to use it, and beware something will break, certainly. > > The biggest broken thing - is libudev.so.0 > Systemd provides libudev.so.1 > > Upgrade should be done very carefully. No, the biggest breakage right now is that systemd installs udev some other place and udev-gentoo-scripts won't handle it. So, installing this version effectively breaks OpenRC.
(In reply to comment #16) > The biggest broken thing - is libudev.so.0 > Systemd provides libudev.so.1 So, systemd's libudev.so.1 not compatible with libudev.so.0, most of packages which used libudev does not compiles. I have a few questions, about correct opening bugs in such sitations: 1. should I open bugs on packages, which depends on udev? They should be configured to accept systemd as dependency, or some virtual/udev will be available? (I remind that they are not compatible) 2. a lot of packages doesn't compiles with systemd's udev, should I open bugs, or wait for smth?
(In reply to comment #18) > (In reply to comment #16) > > The biggest broken thing - is libudev.so.0 > > Systemd provides libudev.so.1 > So, systemd's libudev.so.1 not compatible with libudev.so.0, most of > packages which used libudev does not compiles. > > I have a few questions, about correct opening bugs in such sitations: > 1. should I open bugs on packages, which depends on udev? They should be > configured to accept systemd as dependency, or some virtual/udev will be > available? (I remind that they are not compatible) > 2. a lot of packages doesn't compiles with systemd's udev, should I open > bugs, or wait for smth? Answer to 1. is definitely not at this time. Answer to 2. is only for those packages that break due to symbols removed from libudev (udev_monitor_new_from_socket,udev_monitor_new_from_netlink, etc. ) or changes in udev_foo_unref making their return type 'struct udev_foo' instead of 'void'.
(In reply to comment #13) > For now, I've committed systemd-185 with blocker on udev. If anyone wants, > feel free to test it. It has no Gentoo patches or files (which were in udev > ebuild), and you need to put udev in package.provided to use it. Now, I have been chatting with some of our devs on irc, and there might be a better way to handle this. But, we need systemd to *not* install any of the udev parts. So, please rework the systemd-185 ebuild to not install the udev parts. I also see that bugs have been opened; this was premature, and they should be closed as invalid and removed from this bug.
(In reply to comment #20) > (In reply to comment #13) > > For now, I've committed systemd-185 with blocker on udev. If anyone wants, > > feel free to test it. It has no Gentoo patches or files (which were in udev > > ebuild), and you need to put udev in package.provided to use it. > > Now, I have been chatting with some of our devs on irc, and there might be a > better way to handle this. But, we need systemd to *not* install any of the > udev parts. So, please rework the systemd-185 ebuild to not install the udev > parts. I don't really like this approach. This implies either removing a random number of files which were built already which is a no-go, or heavy patching of the build system and maintaining that which is not friendly either. It will be probably easier to mask systemd for removal :P.
(In reply to comment #20) > I also see that bugs have been opened; this was premature, and they should > be closed as invalid and removed from this bug. I have a bit different opinion. This bugs are opened, because of API/ABI changes in libudev.so - and it doesn't matter which package will provide this library. I would like to mark, which packages becomes broken in a moment (and recompilation doesn't helps) if libudev.so.1 will be installed right now.
This will be in the tree shortly.
(In reply to comment #23) > This will be in the tree shortly. ...and what was the conclusion of the "discussion" with upstream ? Cause unless I've missed a mail, it ended up on a note "it's our way or the highway" from upstream (or at least the main dev).
Udev-186 is in the tree. we found a way to make their build system work for us for the time being.
