Created attachment 383102 [details] emerge --info sys-apps/openrc sys-fs/udev-init-scripts virtual/libgudev virtual/libudev virtual/udev I'm one of those silly people who have "systemd" installed in order to provide "udev", because I have it around because I want to keep trying it to see if it "works" or not. But this means that this atom: !<sys-fs/udev-init-scripts-27 In conjunction with the fact I had sys-fs/udev-init-scripts-26-r2 Resulted in portage deciding the resolution was "remove udev-init-scripts". Which of course, lead me to have a rather broken system when I booted up. I spent ages trying to work out why X.Org wasn't working, why it had no input devices, and why rebuilding the input devices as usual had no consequence. I also had weird problems with the network coming up which hampered my ability to solve the problem. Fortunately the good folks in freenode#gentoo helped me realize "Hey, you don't have udev running, thats probably bad" and led me to discover that the init script I saw being removed 8 hours earlier when I updated openrc, was in fact, something that was bad =)
OpenRC-0.13 requires at least udev-init-scripts-27 which is in ~arch, that is why it has a blocker on older versions. I recommend that you do the following: 1. echo sys-fs/udev-init-scripts >> /etc/portage/package.keywords 2. emerge udev-init-scripts That puts udev-init-scripts in your world file, which you will need if system is installed.
@systemd: I don't recommend adding back the dependency on u-i-s since a pure systemd system doesn't need it, but I would tell people how to handle the transition some how. Thanks, William
Created attachment 383136 [details, diff] udev-init-scripts.patch This is a patch for systemd-9999.ebuild which will add this warning. This, or something similar, should be applied to all versions of the systemd ebuild. Thanks, William
Created attachment 383148 [details, diff] udev-init-scripts.patch Here is an updated version with white space fixes. Thanks, William
This patch was applied to all systemd ebuilds, thanks to floppym for the review.
(In reply to William Hubbs from comment #1) > OpenRC-0.13 requires at least udev-init-scripts-27 which is in ~arch, that > is why it has a blocker on older versions. > > I recommend that you do the following: > > 1. echo sys-fs/udev-init-scripts >> /etc/portage/package.keywords > 2. emerge udev-init-scripts > > That puts udev-init-scripts in your world file, which you will need if > system is installed. I have KEYWORDS="~arch" globally, so portage *could* have upgraded it already. It just elected not to, and elected to remove it instead. But thanks for the systemd fix anyway. IMHO a warning is probably not strong enough considering missing that warning can easily lead to an unusuable system, but a warning is better than none. I'd even be more inclined to have a similar warning in openrc itself.
The problem of the message is that it's not shown when, as just occurred me, people upgrade their systems and, later, they see depclean wanting to remove it. I reviewed that one since I knew that it was needed by openRC but we cannot pretend people will know that and they will see openRC is not booting next time they try :/ What is the problem in pulling init.d scripts unconditionally? It looks to me like a similar policy as we currently do for systemd unit files, that are installed always even for people not installing systemd at all. Other option would be to rely on a "openrc" USE flag as eudev ebuilds do :/
17 Aug 2014; Mike Gilbert <floppym@gentoo.org> systemd-212-r5.ebuild, systemd-215-r3.ebuild, systemd-9999.ebuild: Drop dependency to avoid pulling openrc into the depgraph via udev-init- scripts-27. I saw this... but I cannot see openrc being pulled by udev-init-scripts-27 neither RDEPEND=">=virtual/udev-180 !<sys-fs/udev-186 !<sys-apps/openrc-0.13" DEPEND="${RDEPEND}"
(In reply to Pacho Ramos from comment #8) > 17 Aug 2014; Mike Gilbert <floppym@gentoo.org> systemd-212-r5.ebuild, > systemd-215-r3.ebuild, systemd-9999.ebuild: > Drop dependency to avoid pulling openrc into the depgraph via udev-init- > scripts-27. > > I saw this... but I cannot see openrc being pulled by udev-init-scripts-27 > neither William changed the dependency to a blocker the day after I dropped the udev-init-scripts dependency from systemd. This was after we had discussed the issue, and he had expressed that he did not think the original dependency was incorrect. http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-fs/udev-init-scripts/udev-init-scripts-27.ebuild?r1=1.1&r2=1.2 If you want to add the udev-init-scripts dependency back, I really don't care at this point. I just find it really annoying to have openrc pulled into my depgraph.
To be clear, I don't think William did anything wrong here; he asked for other opinions and changed his mind, which is fine. He alerted me to it, and I decided to not to restore the dependency. Again, I have no objection to restoring it now, so please do so if you think it makes more sense.
(In reply to Mike Gilbert from comment #10) > To be clear, I don't think William did anything wrong here; he asked for > other opinions and changed his mind, which is fine. He alerted me to it, and > I decided to not to restore the dependency. > > Again, I have no objection to restoring it now, so please do so if you think > it makes more sense. As far as I understand it, systemd doesn't require udev-init-scripts, so it shouldn't have a hard dependency on it. At least, I'm pretty sure it isn't required since the box I'm typing this on doesn't seem to need it. I'd suggest just adding a note to the systemd install guide that indicates when you need it, or otherwise communicate this info to the user. Maybe an openrc USE flag might make sense, though we generally avoid this just for dependencies.
It is a runtime dep if we support systemd ebuild as udev provider (and I think we were supporting that too instead of forcing all people not willing to run full systemd to run the udev ebuilds). Also, I wouldn't like to start some kind of flame between we optionally installing init.d files. Also, my main point is to allow to run both (openRC/systemd). For example, last time I needed to boot with openRC was due systemd simply faing to boot at all due a problem with plymouth, then, I booted with openRC and fixed it from there... it would have been terrible to see openRC stopped working due udev-init-scripts being cleaned time ago :S In summary, from my point of view every package should install systemd unit files and init.d openRC scripts to be able to use them on both init systems. This would include also systemd package being used as udev provider :)
I would be with Rich on this. The syslg/logrotate/etc policy doesn't apply because the init scripts are a separate package. Pure system systems don't need them, so I disagree with the comment about forcing them to be installed. If someone wants to use system as their udev provider under OpenRC, they need to have the scripts, but that's the only situation where they are needed. The only reason system is listed in virtual/udev is to keep another provider from being installed.
(In reply to William Hubbs from comment #13) > I would be with Rich on this. The syslg/logrotate/etc policy doesn't apply > because the init scripts are a separate package. Pure system systems don't > need them, so I disagree with the comment about forcing them to be installed. > > If someone wants to use system as their udev provider under OpenRC, they > need to have the scripts, but that's the only situation where they are > needed. > But this is the case for every user (like me) that have systemd ebuild installed: until now, you were able to reboot with openRC without major issues. With this changes (if you don't know what udev-init-scripts is for), people will break their openrc setup as soon as they update and depclean things :/ This also show me how inconsistently we are handling udev init.d scripts currently: - sys-fs/udev -> provides init.d scripts due hard depend on udev-init-scripts - sys-fs/eudev -> provides init.d scripts if people set "openrc" USE flag - sys-apps/systemd -> doesn't provide them and people need to read a message for that (a message that will only be shown if udev-init-scripts is not installed at the time systemd package is emerged) We should at least be consistent to not require people to read every ebuild to figure out what to do for being able to reboot with udev using openRC From my point of view we should always provide init.d scripts and systemd unit files to let people to switch more easily between init systems (I remember when we needed to make efforts in the past to allow this, killing some USE flags usages that were requiring useless rebuildings and similar to switch between init systems). But will see what other parts think. Anyway, I think we should be more consistent with the way we provide the init.d scripts instead of needing to use different ways for udev,systemd and eudev ebuilds
(In reply to Pacho Ramos from comment #14) > > From my point of view we should always provide init.d scripts and systemd > unit files to let people to switch more easily between init systems (I > remember when we needed to make efforts in the past to allow this, killing > some USE flags usages that were requiring useless rebuildings and similar to > switch between init systems). Oh, I agree that packages should generally support both init systems when it is just a matter of installing an init script or unit. My main concern was having openrc pulled into the depgraph, but it looks like that issue was already fixed, if it ever was a problem. I do think we should be consistent across all three udev implementations. Having USE=openrc for eudev and not udev/systemd doesn't really make sense.
Since it is not pulling openrc and udev-init-scripts has really a small buildtime cost, I would simply pull it unconditionally for all of them (the problem of using "openrc" USE flag is that it would require to rebuild the package only for installing that files)
sys-fs/udev is fine with always installing init scripts as per existing policies
(In reply to Samuli Suominen from comment #17) > sys-fs/udev is fine with always installing init scripts as per existing > policies So far as I am aware, sys-fs/eudev is fine with dropping the use flag and making udev-init-scripts a hard dep, too. We will likely do that for the next release. And now, back to your originally scheduled bug topic.
I'm going to officially weigh-in and say we should hard-depend on udev-init-scripts again. Pacho has summarized the issue fairly well.
If someone can point me to a policy in the dev manual that requires us to always install init scripts, I'll shut up [1]. I think this insistence on hard-depending on sys-fs/udev-init-scripts comes from the day when OpenRC/baselayout-1 was the only init system we supported, so we had to make sure the init scripts were there. Since we now have multiple init systems (at least openrc/sysvinit, runit, system, daemontools, etc), I think this is a good time to rethink this practice. [1] https://devmanual.gentoo.org
(In reply to William Hubbs from comment #20) > If someone can point me to a policy in the dev manual that requires us to > always install init scripts, I'll shut up [1]. > > I think this insistence on hard-depending on sys-fs/udev-init-scripts comes > from the day when OpenRC/baselayout-1 was the only init system we supported, > so we had to make sure the init scripts were there. > > Since we now have multiple init systems (at least openrc/sysvinit, runit, > system, daemontools, etc), I think this is a good time to rethink this > practice. > > [1] https://devmanual.gentoo.org The problem is that this is a dependency; an optional one but a dependency nevertheless. Not specifying the dependency provides a hole for end-users to fall into. Putting it as a use flag means that we may be forcing recompiles of *udev just to get this tiny package containing a couple of small script files installed, which is overkill. Forcing it as a dep brings in a package that installs a couple of small text files, and has little to no impact on systems that aren't going to use it -- exactly the same as how systemd units being installed has little to no impact on systems that aren't going to use them, either. If we had SDEPEND or IUSE_RUNTIME support or similar, then sure it might be better to not depend on the init scripts. But as PMs and the portage tree stand right now, forcing it on makes the most sense. End-users that really don't want the scripts can still package.provides it away or INSTALL_MASK="/etc/init.d/*" (note, i don't know the syntax for INSTALL_MASK).
(In reply to Ian Stakenvicius from comment #21) > The problem is that this is a dependency; an optional one but a dependency > nevertheless. Not specifying the dependency provides a hole for end-users > to fall into. Putting it as a use flag means that we may be forcing > recompiles of *udev just to get this tiny package containing a couple of > small script files installed, which is overkill. Forcing it as a dep brings > in a package that installs a couple of small text files, and has little to > no impact on systems that aren't going to use it -- exactly the same as how > systemd units being installed has little to no impact on systems that aren't > going to use them, either. I just found another case that worksthe way I propose. MySQL can optionally not install the MySQL-init-scripts package based on a use flag setting. If we add IUSE="+openrc" to eudev and udev and IUSE="openrc" to system, that would take care of this issue. Also, scripts are not just small text files; they are executable. So in my mind that makes a difference.
I suppose a middle ground here could be this: 1. sys-fs/udev and sys-fs/eudev could hard dep on udev-init-scripts since they are not run with system. 2. system should use a use flag like "openrc" to depend on udev-init-scripts, if it does at all. I would prefer that system not have the dependency on udev-init-scripts and just warn about it.
(In reply to William Hubbs from comment #23) > 2. system should use a use flag like "openrc" to depend on > udev-init-scripts, if it does at all. I would prefer that system not have > the dependency on > udev-init-scripts and just warn about it. I just want to reiterate that adding an openrc use flag would introduce an optional runtime dependency. I am not personally opposed to doing so, but you have expressed a desire to follow policy to the letter in the past. I am still inclined to add the hard-dep since there is very little downside to that.
The Council already voted that stuff like init scripts should be installed by default. Maybe that is something to revisit, but we should follow that policy until that happens. I think the policy still makes sense though. Why force a big rebuild for a few files?
(In reply to Richard Freeman from comment #25) > The Council already voted that stuff like init scripts should be installed > by default. Maybe that is something to revisit, but we should follow that > policy until that happens. > > I think the policy still makes sense though. Why force a big rebuild for a > few files? Yeah, I completely agree, specially because I remember we all discussed all this time ago when some people wanted to install systemd unit files depending on a "systemd" USE flag... I would be really surprised if we start now to do the same for "openrc" :/ And the main issue of using USE flags was that we were forcing people to rebuild packages only to install a set of files that don't collide between them (systemd USE flag is only being used if it changes something in the behavior of the package, I remember the big lxnay effort some time ago to do this a bit before I even joined to systemd and I started to use it).
(In reply to Pacho Ramos from comment #26) > (In reply to Richard Freeman from comment #25) > > The Council already voted that stuff like init scripts should be installed > > by default. Maybe that is something to revisit, but we should follow that > > policy until that happens. The council has discussed this, but there has never been a formal vote. It is more like a strongly encouraged practice, but there is no official policy on the issue, and I feel that with the addition of --newuse and --changed-use to portage we should revisit it, but that should happen on the ml, not this bug. > > I think the policy still makes sense though. Why force a big rebuild for a > > few files? > > Yeah, I completely agree, specially because I remember we all discussed all > this time ago when some people wanted to install systemd unit files > depending on a "systemd" USE flag... I would be really surprised if we start > now to do the same for "openrc" :/ > > And the main issue of using USE flags was that we were forcing people to > rebuild packages only to install a set of files that don't collide between > them (systemd USE flag is only being used if it changes something in the > behavior of the package, I remember the big lxnay effort some time ago to do > this a bit before I even joined to systemd and I started to use it). Consider this scenario: I don't want logrotate files, xinetd files, or system units on my system. Using the current system, I would use install_mask to mask out /etc/logrotate.d, /etc/xinet.d and /usr/lib/system/system then remove those directories. If at some point later I decide I want logrotate files back, the only choice I have is to fix install_mask then emerge -e @world. On the other hand, if we used logrotate, xinet and system use flags, all I would have to do is change these settings in make.conf or package.use then run emerge --changed-use @world. So, my question is: should we be forcing users to rebuild the world for this issue? I realize that rebuilding a package for small text files may seem a waste, but forcing a rebuild of the world is more of a waste imo.
(In reply to William Hubbs from comment #27) > (In reply to Pacho Ramos from comment #26) > > (In reply to Richard Freeman from comment #25) > > > The Council already voted that stuff like init scripts should be installed > > > by default. Maybe that is something to revisit, but we should follow that > > > policy until that happens. > > The council has discussed this, but there has never been a formal vote. It > is more like a strongly encouraged practice, but there is no official policy > on the issue, and I feel that with the addition of --newuse and > --changed-use to portage we should revisit it, but that should happen on the > ml, not this bug. You are not correct here. As far as I'm aware, both options precede the relevant Council meeting, and --newuse is in portage for ages. And in case, neither is really relevant since it wasn't the problem of being able to find what to rebuild. > Consider this scenario: > > I don't want logrotate files, xinetd files, or system units on my system. > > Using the current system, I would use install_mask to mask out > /etc/logrotate.d, /etc/xinet.d and /usr/lib/system/system then remove those > directories. If at some point later I decide I want logrotate files back, > the only choice I have is to fix install_mask then emerge -e @world. $ emerge app-portage/install-mask $ install-mask --rebuild It will find the packages with missing files and rebuild them. > On the other hand, if we used logrotate, xinet and system use flags, all I > would have to do is change these settings in make.conf or package.use then > run emerge --changed-use @world. > > So, my question is: should we be forcing users to rebuild the world for this > issue? I realize that rebuilding a package for small text files may seem a > waste, but forcing a rebuild of the world is more of a waste imo. You are missing a major point. By making this USE flag selectable, you encourage people to switch it frequently. Keeping it as INSTALL_MASK you make it 'change it on your own responsibility, you have been warned that it is a very dumb thing to do'.
I would re-add the dep then (I think the full discussion about installing systemd unit / init.d files deserves a really big thread as the one that already had past year to discuss that again :/)
(In reply to Michał Górny from comment #28) > (In reply to William Hubbs from comment #27) > > (In reply to Pacho Ramos from comment #26) > > > (In reply to Richard Freeman from comment #25) > > > > The Council already voted that stuff like init scripts should be installed > > > > by default. Maybe that is something to revisit, but we should follow that > > > > policy until that happens. > > > > The council has discussed this, but there has never been a formal vote. It > > is more like a strongly encouraged practice, but there is no official policy > > on the issue, and I feel that with the addition of --newuse and > > --changed-use to portage we should revisit it, but that should happen on the > > ml, not this bug. > > You are not correct here. As far as I'm aware, both options precede the > relevant Council meeting, and --newuse is in portage for ages. And in case, > neither is really relevant since it wasn't the problem of being able to find > what to rebuild. My point above was just to say that there is not a formal policy on this, it is just something we do. > > Consider this scenario: > > > > I don't want logrotate files, xinetd files, or system units on my system. > > > > Using the current system, I would use install_mask to mask out > > /etc/logrotate.d, /etc/xinet.d and /usr/lib/system/system then remove those > > directories. If at some point later I decide I want logrotate files back, > > the only choice I have is to fix install_mask then emerge -e @world. > > $ emerge app-portage/install-mask > $ install-mask --rebuild > > It will find the packages with missing files and rebuild them. app-portage/install-mask is completely unnecessary if you leverage the options in portage properly. > > > On the other hand, if we used logrotate, xinet and system use flags, all I > > would have to do is change these settings in make.conf or package.use then > > run emerge --changed-use @world. > > > > So, my question is: should we be forcing users to rebuild the world for this > > issue? I realize that rebuilding a package for small text files may seem a > > waste, but forcing a rebuild of the world is more of a waste imo. > > You are missing a major point. By making this USE flag selectable, you > encourage people to switch it frequently. Keeping it as INSTALL_MASK you > make it 'change it on your own responsibility, you have been warned that it > is a very dumb thing to do'. I don't see this as a major point. Also, I see one of the key strengths of Gentoo as use flags, and if we can easily leverage them to provide support for things that upstream supports by configure switches for example, or for things we do downstream, I think we should. wrt this being a dumb thing to do, we are all going to havedifferent opinions about what is dumb, so I'm not sure a discussion about that would lead anywhere.
Are we actually adding this as a dep or not? It seemed like all of us basically were agreeing that this was what we were going to do, but this has been sidetracked into a theoretical discussion about what is and is not permissible with installing scripts controlled by USE flags. Setting aside whether or not the Council ever decided on anything, are we agreed on just adding this as a dependency to systemd? If so, I suggest we just do so and close this out. If we aren't agreed and there is a policy question I can stick this on the next Council agenda. Discussing the pros/cons here isn't likely to resolve anything.
+ 14 Sep 2014; Pacho Ramos <pacho@gentoo.org> systemd-212-r5.ebuild, + systemd-215-r3.ebuild, systemd-216.ebuild, systemd-9999.ebuild: + Ensure udev init.d scripts are installed to not break booting with openRC + (#520224) + Reassigning to eudev people to stop relying on USE flag for this (comment #18)
(In reply to Pacho Ramos from comment #32) > + 14 Sep 2014; Pacho Ramos <pacho@gentoo.org> systemd-212-r5.ebuild, > + systemd-215-r3.ebuild, systemd-216.ebuild, systemd-9999.ebuild: > + Ensure udev init.d scripts are installed to not break booting with openRC > + (#520224) > + > > Reassigning to eudev people to stop relying on USE flag for this (comment > #18) Sorry coming late to this discussion, but are you suggesting we just drop USE=openrc and install >=sys-fs/udev-init-scripts-26 unconditionally?
Yes :)
I love Gentoo for a way that it can be customized and welcome any change that adds one more package to my "emerge --depclean" list. But such changes makes me sad. Completely agree with William
(In reply to Pacho Ramos from comment #34) > Yes :) Pacho, I don't see a bug here with the conditional dependency on USE=openrc. This seems to be a preference and not a bug. I'll think about it, but I'm really not sure this is the right thing to do.
(In reply to Anthony Basile from comment #36) > (In reply to Pacho Ramos from comment #34) > > Yes :) > > Pacho, I don't see a bug here with the conditional dependency on USE=openrc. > This seems to be a preference and not a bug. I'll think about it, but I'm > really not sure this is the right thing to do. So, the council did decide that packages shouldn't use USE flags to merely control the installation of init scripts and units a year or so ago. It sounds like we're still debating the meaning of that decision, and whether it still makes sense. If so, we can always put this in front of the council again. I just think it makes sense to be consistent - it doesn't make sense to have different packages having different conditional behavior here.
(In reply to Richard Freeman from comment #37) > (In reply to Anthony Basile from comment #36) > > (In reply to Pacho Ramos from comment #34) > > > Yes :) > > > > Pacho, I don't see a bug here with the conditional dependency on USE=openrc. > > This seems to be a preference and not a bug. I'll think about it, but I'm > > really not sure this is the right thing to do. > > So, the council did decide that packages shouldn't use USE flags to merely > control the installation of init scripts and units a year or so ago. > > It sounds like we're still debating the meaning of that decision, and > whether it still makes sense. If so, we can always put this in front of the > council again. > > I just think it makes sense to be consistent - it doesn't make sense to have > different packages having different conditional behavior here. Okay, I'll remove the USE=openrc flag from eudev ebuilds from this point on. I'm in the middle of stabilizing eudev-1.10-r2 and I don't want to mess with it now. I guess what confuses me is that we have other init systems available, like runit. For consistency, should we also install their init scripts? Or should we standardize on just openrc and systemd unit files. I guess I am still debating the meaning of what we want here.
(In reply to Anthony Basile from comment #38) > > I guess what confuses me is that we have other init systems available, like > runit. For consistency, should we also install their init scripts? Or > should we standardize on just openrc and systemd unit files. I guess I am > still debating the meaning of what we want here. It isn't required for any package to supply openrc, systemd, runit scripts, logrotate configurations, tmpreaper/tmpfiles configurations, bash completion recipes, and so on. However, if they do provide them, they should provide them unconditionally. Maintainers don't have to go out of their way to create all of this stuff, but if somebody wants to contribute them they're welcome to do so as long as it makes sense, and maintainers should generally be good sports about it or at least stay out of the way if somebody else wants to do the work. USE flags should be reserved for cases where enabling support for something like the above involves linking in dependencies and things of that nature. I think that is the gist of the current policy.
(In reply to Richard Freeman from comment #39) > (In reply to Anthony Basile from comment #38) > > > > I guess what confuses me is that we have other init systems available, like > > runit. For consistency, should we also install their init scripts? Or > > should we standardize on just openrc and systemd unit files. I guess I am > > still debating the meaning of what we want here. > > It isn't required for any package to supply openrc, systemd, runit scripts, > logrotate configurations, tmpreaper/tmpfiles configurations, bash completion > recipes, and so on. > > However, if they do provide them, they should provide them unconditionally. > Maintainers don't have to go out of their way to create all of this stuff, > but if somebody wants to contribute them they're welcome to do so as long as > it makes sense, and maintainers should generally be good sports about it or > at least stay out of the way if somebody else wants to do the work. > > USE flags should be reserved for cases where enabling support for something > like the above involves linking in dependencies and things of that nature. > > I think that is the gist of the current policy. I think the part where current policy falls down here, is that udev-init-scripts is its own separate package. If the scripts where part of sys-fs/udev or eudev itself, then i think it would be clear and that there is no question these scripts should be installed unconditionally. However when it's a dep, it's a separate package, and the question then becomes should we really hard-dep on something that is only useful under certain circumstances? To be honest, i think the optional way to do this would probably be that udev-init-scripts becomes a dep of openrc[udev] rather than *udev[openrc]; udev being a global use flag that isn't strictly necessary to hav eudev playing as dev manager but is generally used anyways to ensure everything else in the system has its optional udev support enabled. That said, though, i'm personally fine with udev, eudev and systemd hard-depending on udev-init-scripts. The only cruft a user has with an INSTALL_MASK on /etc/init.d is one extra entry in vdb, and that doesn't hurt very much.
If the scripts were part of the package, we'd have to keep (in sync) three copies of them :). Anyway, I see three possible good solutions here: 1) USE=openrc on udev providers -- since it controls a dep, the flag is ok; 2) USE=udev on openrc -- may be a little confusing but I guess it'd be an acceptable logic, 3) unconditional on udev providers. As I see it, different providers may use different choices -- e.g. it sounds more reasonable to have sys-fs/udev always pull in openrc scripts while systemd do that optionally. However, consistency has its advantages too. But that's just a matter of expressing opinion. I'm fine with all options that don't break users' systems.
(In reply to Michał Górny from comment #41) > If the scripts were part of the package, we'd have to keep (in sync) three > copies of them :). > > Anyway, I see three possible good solutions here: > > 1) USE=openrc on udev providers -- since it controls a dep, the flag is ok; > 2) USE=udev on openrc -- may be a little confusing but I guess it'd be an > acceptable logic, I would disagree with this since it is weird reverse logic. > 3) unconditional on udev providers. > > As I see it, different providers may use different choices -- e.g. it sounds > more reasonable to have sys-fs/udev always pull in openrc scripts while > systemd do that optionally. However, consistency has its advantages too. The more I think about this, for now, what I am leaning toward is, sys-fs/udev and sys-fs/eudev could hard dep on udev-init-scripts since we only support starting them with OpenRC and sys-apps/system should use an openrc use flag since it is more likely that once someone has system installed they will boot with it and it will start udev itself.
(In reply to William Hubbs from comment #42) > (In reply to Michał Górny from comment #41) > > If the scripts were part of the package, we'd have to keep (in sync) three > > copies of them :). > > > > Anyway, I see three possible good solutions here: > > > > 1) USE=openrc on udev providers -- since it controls a dep, the flag is ok; > > 2) USE=udev on openrc -- may be a little confusing but I guess it'd be an > > acceptable logic, > > I would disagree with this since it is weird reverse logic. > > > 3) unconditional on udev providers. > > > > As I see it, different providers may use different choices -- e.g. it sounds > > more reasonable to have sys-fs/udev always pull in openrc scripts while > > systemd do that optionally. However, consistency has its advantages too. > > The more I think about this, for now, what I am leaning toward is, > sys-fs/udev and sys-fs/eudev could hard dep on udev-init-scripts since we > only support starting them with OpenRC and sys-apps/system should use an > openrc use flag since it is more likely that once someone has system > installed they will boot with it and it will start udev itself. Moving foward, I've removed the conditonal dep on sys-fs/udev-init-scripts. I'm going to close this bug as done, but of course the discussion can continue elsewhere.
