| Summary: | sys-apps/systemd doesn't install required systemd units (was: sys-fs/udev-187-r2 does not install systemd units) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Florian Scandella <flo> |
| Component: | [OLD] Core system | Assignee: | udev maintainers <udev-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | trivial | CC: | arne.flagge, axs, egorov_egor, nikoli, peter.saaf, systemd, tdalman |
| Priority: | Low | Keywords: | NeedPatch |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Florian Scandella
2012-08-08 16:11:33 UTC
I have spoken with the other udev maintainer about this, and we both feel that udev shouldn't install the systemd units. Also, there is no technical reason that systemd is required to use the bundled udev. My thoughts on this now are that the systemd ebuild should be modified to install the udev systemd units and build and install systemd but leave the udev portion to the udev ebuild. I will be proposing a patch to the systemd-187 ebuild to do this. (In reply to comment #1) > I have spoken with the other udev maintainer about this, and we both > feel that udev shouldn't install the systemd units. > > Also, there is no technical reason that systemd is required to use the > bundled udev. My thoughts on this now are that the systemd ebuild should > be modified to install the udev systemd units and build and install > systemd but leave the udev portion to the udev ebuild. This is getting idiotic. Either let me install both systemd and udev, or stop throwing the ball around and choosing random parts of udev you won't be installing. I really don't see how I am supposed to install systemd in /usr yet install systemd units for udev installed in rootfs. (In reply to comment #3) > This is getting idiotic. Either let me install both systemd and udev, or > stop throwing the ball around and choosing random parts of udev you won't be > installing. I really don't see how I am supposed to install systemd in /usr > yet install systemd units for udev installed in rootfs. Check udev-187-r3. Samuli also thought that udev should be in /usr, and we got a patch that makes it possible. The issue that was holding it back was the helpers, but this has been taken care of by a patch from Egor Egorov on bug #430412. Could you please fix this problem or work it around quickly? Currently my systemd-based system is probably unbootable (at least I would not risk rebooting it without the udev unit). To work this around I'm forced to either extract all the units by hand and install them in /etc, to downgrade udev or to unmask the systemd of newer versions from hard mask. Please dot't be rude and don't break the systems for everyone using the unstable udev and systemd. Why have a separate package for systemd at all? I would love to see patch against sys-fs/udev that adds USE="systemd" and installs rest of the package based on it. (In reply to comment #6) > Why have a separate package for systemd at all? > I would love to see patch against sys-fs/udev that adds USE="systemd" and > installs rest of the package based on it. systemd is not part of udev and it never was. Go find your own playground. (In reply to comment #7) > (In reply to comment #6) > > Why have a separate package for systemd at all? > > I would love to see patch against sys-fs/udev that adds USE="systemd" and > > installs rest of the package based on it. > > systemd is not part of udev and it never was. Go find your own playground. I hope you realize the other alternative is playing catch up with udev's ebuild. Futher your comment seems to have some sort of attitude attached to it which I'm going to keep on ignoring, too childish for me. (In reply to comment #6) > Why have a separate package for systemd at all? > I would love to see patch against sys-fs/udev that adds USE="systemd" and > installs rest of the package based on it. As a user i think this would be the best thing to do. Having 2 packages from the same source from two different maintainers which, assuming from the comments, don't work well together is just asking for trouble. (In reply to comment #6) > Why have a separate package for systemd at all? > I would love to see patch against sys-fs/udev that adds USE="systemd" and > installs rest of the package based on it. I have had several discussions on IRC wrt this topic, and several developers, including myself, agree that a udev ebuild with a systemd use flag is the best way to go. This would not be a hard patch to write, and I could write it myself easily. I will do a proof-of-concept patch here in fact to prove my point. (In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > Why have a separate package for systemd at all? > > > I would love to see patch against sys-fs/udev that adds USE="systemd" and > > > installs rest of the package based on it. > > > > systemd is not part of udev and it never was. Go find your own playground. > > I hope you realize the other alternative is playing catch up with udev's > ebuild. > Futher your comment seems to have some sort of attitude attached to it which > I'm going to keep on ignoring, too childish for me. I got bored of being 'so adult' when you started to run in circles and change your decisions back and forth. (In reply to comment #9) > (In reply to comment #6) > > Why have a separate package for systemd at all? > > I would love to see patch against sys-fs/udev that adds USE="systemd" and > > installs rest of the package based on it. > > As a user i think this would be the best thing to do. Having 2 packages from > the same source from two different maintainers which, assuming from the > comments, don't work well together is just asking for trouble. Yes, your system will certainly be more likely to work when the main component of the system would be maintained as a side flag by people who don't run it. (In reply to comment #11) > Yes, your system will certainly be more likely to work when the main > component of the system would be maintained as a side flag by people who > don't run it. I know i'm in no position to tell you what to do, but whats the difference in: a) maintaining an extra ebuild, duplicating udev changes and watch for file collisions. b) help maintaining the systemd part of udev. I think the logical package name to go for would be systemd with an extra udevonly flag, but there are so many packages depending on udev, this would cause rebuild hell for users. (In reply to comment #12) > I know i'm in no position to tell you what to do, but whats the difference > in: > > a) maintaining an extra ebuild, duplicating udev changes and watch for file > collisions. > b) help maintaining the systemd part of udev. @florian: Here is the deal from my pov. It would be much easier for mgorny to work with the udev team and help maintain the systemd portion of the udev ebuild. I have had many conversations with him about doing exactly this, and his primary objection is that he doesn't like our coding style. He has the systemd ebuild the way he wants it and he doesn't want any other devs messing with it. > I think the logical package name to go for would be systemd with an extra > udevonly flag, but there are so many packages depending on udev, this would > cause rebuild hell for users. That among other reasons is exactly why this can't happen. It would create a very complicated situation, both technically and politically. :-) (In reply to comment #13) > (In reply to comment #12) > > I think the logical package name to go for would be systemd with an extra > > udevonly flag, but there are so many packages depending on udev, this would > > cause rebuild hell for users. > > That among other reasons is exactly why this can't happen. It would create a > very complicated situation, both technically and politically. :-) Personally, I'd like to see udev and systemd being merged into a single package. I like Samulis proposal, though I don't understand your 'political' issues. TBH, I don't even care. What I care for is this bug, so, please, fix it. I'm eager to help or test out new ebuilds. I've added a dependency on older udev to systemd to ensure that udev maintainers mood swings won't break running systems. Well, as for that: it broke my system, because Gnome3 depends on >=udev-180. That's a whole mess and I'm quite upset about your internal quarrels. I have switched back to sysv-init, but I hope the problems are resolved soon. (In reply to comment #16) > Well, as for that: it broke my system, because Gnome3 depends on >=udev-180. > That's a whole mess and I'm quite upset about your internal quarrels. > > I have switched back to sysv-init, but I hope the problems are resolved soon. udev-187-r1 works fine with systemd-44-r1 for me. you can't build an initrd with it (at least not with dracut), but if you have an existing one around it boots. not saying that i don't wont this to be resolved ASAP :) (In reply to comment #17) > (In reply to comment #16) > > Well, as for that: it broke my system, because Gnome3 depends on >=udev-180. > > That's a whole mess and I'm quite upset about your internal quarrels. > > > > I have switched back to sysv-init, but I hope the problems are resolved soon. > > udev-187-r1 works fine with systemd-44-r1 for me. you can't build an initrd > with it (at least not with dracut), but if you have an existing one around > it boots. Thanks, I readjusted the dep for now. Thanks! I'm sorry that I ask here. Is it possible to do virtual/udev[gudev], which would have a dependence of || (sys-fs/udev[=gudev] sys-apps/systemd[=gudev]) or so? (In reply to comment #20) > I'm sorry that I ask here. Is it possible to do virtual/udev[gudev], which > would have a dependence of || (sys-fs/udev[=gudev] sys-apps/systemd[=gudev]) > or so? In theory, virtual/udev is possible, yes, but I don't see the need. If we merge systemd into udev, it would just naturally fall into place without a virtual, and since it is possible to run udev without systemd, I do not see much of a case for keeping them separate. If, on the other hand, we add a virtual, that requires updating the dependencies of 114 packages. I honestly prefer Samuli's proposal as well, but, the systemd maintainer does not. I had another long discussion with him on IRC last night, and he made it pretty clear that he wants to have systemd be his own "silent playground". He doesn't want the rest of us touching his systemd ebuild because he doesn't like our coding style and doesn't want us to force anything onto him. He also stated that he doesn't care about what would be easier for the majority of users or developers. He told me that if I provide a patch that makes the systemd ebuild not install udev, he will consider that. If he accepts it we do not need a virtual. The only problem is if he rejects it we are back to where we started. I will not have time until Monday to do this, but it will be done for systemd-188 that day. (In reply to comment #6) > Why have a separate package for systemd at all? > I would love to see patch against sys-fs/udev that adds USE="systemd" and > installs rest of the package based on it. +1(ish) Given that the latest udev ebuild(s) build everything and then strip out all the systemd bits (because there's no other choice when using upstream's package), it makes the most sense from a unitary packaging perspective to have the udev package optionally install the systemd bits based on USE="systemd". There are a couple of issues with this, mainly that the systemd side of things has a number of additional optional config settings which will need to be mapped to use flags, and wont have any affect at all on the package output if USE="-systemd". Potentially this will trigger unnecessary rebuilds of udev when users change their use flags. However, trying to maintain and sync two separate packages from the same single upstream package has bigger disadvantages: 1 - it is highly unlikely that two separate versions of udev and systemd would work with one-another -- that is, their versions most likely need to match. Maintained separately (the way they are now) requires significantly more cooperation between the maintainer teams than what i've seen so far. Also see #3. 2 - udev and systemd as separate packages would end up building the whole thing twice on a user's system instead of once. 3 - the systemd package is and will continue to be maintained to match what upstream provides as verbatum as possible (ask mgorny for details). This means it's providing udev too, which means it's directly conficting with the udev ebuilds. As #3 is the case, I don't see a problem with allowing the systemd package to continue to exist and provide the near-identical upstream experience, while the udev package provides a udev (and optional systemd) which is massaged as much as is necessary to fit with gentoo as best as it can. True-blue systemd users can use the systemd package, and udev[systemd] can be maintained for eventual inclusion into the stable arches. If assimilating so that only one package in the tree would provide systemd at all, I think that udev[systemd] would be the better option despite the name; however this would mean that the maintainers for udev and systemd would need to merge and there seems to be some ideology right now that doesn't mesh between these groups, so providing two alternative packages would probably be the way to go. As a corollary, I think it would be pertinent to add some form of udev virtual to support this as well as make integration of a forked udev (if one should materialize in the future) easier. Also, it seems that some (perhaps many?) packages depending on udev no longer need to do so as they may have been using udev to do what other services now do; so perhaps *DEPEND'ing on udev should be evaluated and cleaned up throughout the tree anyways (which we can do while converting packages to the virtual).[1] [1] yes, i'm volunteering to HELP; i don't have the expertise to actually head up this work, though. (In reply to comment #21) > (In reply to comment #20) > > I'm sorry that I ask here. Is it possible to do virtual/udev[gudev], which > > would have a dependence of || (sys-fs/udev[=gudev] sys-apps/systemd[=gudev]) > > or so? > > In theory, virtual/udev is possible, yes, but I don't see the need. > > If we merge systemd into udev, it would just naturally fall into place > without a virtual, and since it is possible to run udev without systemd, I > do not see much of a case for keeping them separate. That's your theory. You're harassing me for over a week and not even trying to see my point. > If, on the other hand, we add a virtual, that requires updating the > dependencies of 114 packages. I volunteered. Now I see that not only me. And you already know that some day the virtual will be needed anyway, and then all systemd users will be again on the swing moving on to another ebuild. > I honestly prefer Samuli's proposal as well, but, the systemd maintainer > does not. I had another long discussion with him on IRC last night, and he > made it pretty clear that he wants to have systemd be his own "silent > playground". He doesn't want the rest of us touching his systemd ebuild > because he doesn't like our coding style and doesn't want us to force > anything onto him. He also stated that he doesn't care about what would be > easier for the majority of users or developers. It's nice that you can exactly rephrase my intents. I also want to break every system out there, do not forget. > He told me that if I provide a patch that makes the systemd ebuild not > install udev, he will consider that. If he accepts it we do not need a > virtual. The only problem is if he rejects it we are back to where we > started. Yes, I agreed on that compromise. Then you started to harass me again. I start to doubt it is worth discussing with you at all because you seem not to accept anything other than your I-know-it-best. And you still didn't show me how are you going to solve my issue with user patches. > I will not have time until Monday to do this, but it will be done for > systemd-188 that day. And just a note: if you just accepted the virtual instead of showing yours 'I know better how to maintain systemd', we will be done fixing packages already and people would have working systems. (In reply to comment #23) > (In reply to comment #21) > > If, on the other hand, we add a virtual, that requires updating the > > dependencies of 114 packages. > > I volunteered. Now I see that not only me. And you already know that some > day the virtual will be needed anyway, and then all systemd users will be > again on the swing moving on to another ebuild. Could you elaborate that please ? I mean, adding a virtual only makes sense to me, when you have different software tools doing the same thing. But that's surely not the case of udev or systemd. It's the very same package with two different binaries that inherently depend on each other. So, why would you add another (in my eyes unnecessary) virtual ? Please note that this is not personal attack or something. I'm just curious about the technical reasoning here. (In reply to comment #25) > (In reply to comment #23) > > (In reply to comment #21) > > > If, on the other hand, we add a virtual, that requires updating the > > > dependencies of 114 packages. > > > > I volunteered. Now I see that not only me. And you already know that some > > day the virtual will be needed anyway, and then all systemd users will be > > again on the swing moving on to another ebuild. > > Could you elaborate that please ? I mean, adding a virtual only makes sense > to me, when you have different software tools doing the same thing. But > that's surely not the case of udev or systemd. It's the very same package > with two different binaries that inherently depend on each other. So, why > would you add another (in my eyes unnecessary) virtual ? Please note that > this is not personal attack or something. I'm just curious about the > technical reasoning here. Because two packages provide libudev already: one is systemd, other is Gentoo minimal udev. Moreover, considering upstream's decisions and the arising requests from Gentoo developers and users, it is likely that udev will be forked soon, and then there will be also udev-fork which will provide libudev. (In reply to comment #25) > (In reply to comment #23) > > (In reply to comment #21) > > > If, on the other hand, we add a virtual, that requires updating the > > > dependencies of 114 packages. > > > > I volunteered. Now I see that not only me. And you already know that some > > day the virtual will be needed anyway, and then all systemd users will be > > again on the swing moving on to another ebuild. > > Could you elaborate that please ? I mean, adding a virtual only makes sense > to me, when you have different software tools doing the same thing. But > that's surely not the case of udev or systemd. It's the very same package > with two different binaries that inherently depend on each other. So, why > would you add another (in my eyes unnecessary) virtual ? Please note that > this is not personal attack or something. I'm just curious about the > technical reasoning here. Think vanilla-sources vs gentoo-sources -- that's essentially the type of difference we'd be looking at with these two packages. Plus, the virtual will allow for quick integration of a forked udev in the future if one materializes. (In reply to comment #26) > Because two packages provide libudev already: one is systemd, other is > Gentoo minimal udev. Moreover, considering upstream's decisions and the > arising requests from Gentoo developers and users, it is likely that udev > will be forked soon, and then there will be also udev-fork which will > provide libudev. Thanks for the explanation. Still, I'm not convinced. Why would Gentoo need it's own "minimal" udev ? I mean, it's all there you need. Just take the systemd package and install everything except the systemd binaries. And as for a fork: do you have a reference at hand by chance ? (In reply to comment #28) > (In reply to comment #26) > > Because two packages provide libudev already: one is systemd, other is > > Gentoo minimal udev. Moreover, considering upstream's decisions and the > > arising requests from Gentoo developers and users, it is likely that udev > > will be forked soon, and then there will be also udev-fork which will > > provide libudev. > > Thanks for the explanation. Still, I'm not convinced. Why would Gentoo need > it's own "minimal" udev ? I mean, it's all there you need. Just take the > systemd package and install everything except the systemd binaries. That's a *lot* of compiling because almost everything there is systemd binaries. > And as for a fork: do you have a reference at hand by chance ? No. But many people like talking about it so I believe it will come at some point. In any case, a valid argument has been finally presented in this discussion and I'm working on systemd-188 which would reuse sys-fs/udev. systemd-188 should install the necessary files itself. I'm leaving this bug open since those files should be in udev anyway, and I hope that udev-188 will install *all* files relevant to udev so I could just strip everything related to udev from systemd. Detected file collision(s): /usr/lib/udev/rules.d/61-accelerometer.rules /usr/lib/udev/rules.d/60-persistent-v4l.rules Searching all installed packages for file collisions... Press Ctrl-C to Stop sys-fs/udev-187-r3 /usr/lib/udev/rules.d/60-persistent-v4l.rules /usr/lib/udev/rules.d/61-accelerometer.rules Package 'sys-apps/systemd-188' NOT merged due to file collisions. If necessary, refer to your elog messages for the whole content of the above message. # rm -i /usr/lib/udev/rules.d/60-persistent-v4l.rule # rm -i /usr/lib/udev/rules.d/61-accelerometer.rules # emerge --resume And all ok! very very very thanks. If I understood correctly, there are nothing left to do here for udev-bugs@ since it's systemd's ebuild that should install the systemd units No, udev should install units for udev. Much like every other application installs units for itself. These rules were developed to keep things consistent. I recently saw a comment from upstream that said that as far as they are concerned, udev on non-systemd systems is a dead end, so we may need to re-think integrating the udev and systemd ebuilds. I have posted to both systemd-devel and linux-hotplug asking them what we should do. (In reply to comment #34) > I recently saw a comment from upstream that said that as far as they are > concerned, udev on non-systemd systems is a dead end, so we may need to > re-think integrating the udev and systemd ebuilds. I have posted to both > systemd-devel and linux-hotplug asking them what we should do. So what? If we integrate them, that's equivalent non-systemd systems won't use udev anymore. Unless that happens, there's no need for that. So just bump udev and fix the mistakes in ebuild, so users could get working systems once again. Fixed in udev-188. |
