The other day, Mike and I were chatting on a bug and Mike made the comment that some might see sys-apps/openrc not being part of system as a bug. That started me thinking, and I agree that sys-apps/openrc should not be part of system. However, I think we need a better way to handle openrc and other init scripts implementations. My proposal is to create virtual/initscripts, add it to the system set, and add it to stage1 if it is needed there. Once this is done we could remove PDEPEND entirely from baselayout. The ebuild for virtual/initscripts will be attached to this bug. Any comments or questions are welcome.
Created attachment 278879 [details] initscripts-0.ebuild This is my proposed ebuild for the virtual/initscripts package.
We can also add <sys-apps/baselayout-2 to rdepend for compatibility with baselayout-1 systems if desired.
Please, set HOMEPAGE to something, may be base-system project page? Also I don't like name :) initscripts imply some scripts, while there are binaries too. May be init-system, initsystem, or ... just init?
Hi Peter, (In reply to comment #3) > Please, set HOMEPAGE to something, may be base-system project page? There are over 300 virtuals in the tree, and none of them have a home page. That is why I didn't set one. > Also I don't like name :) initscripts imply some scripts, while there are > binaries too. May be init-system, initsystem, or ... just init? virtual/init already exists and includes packages which provide an implementation of /sbin/init. OpenRC does not provide this, so it can't be included in that virtual. I am open to a better name than initscripts, but I don't know what that would be, because initsystem, etc implies to me that it handles the whole boot process which it doesn't. For your system to be bootable, you will need a package from init and initscripts. Here are some other examples of how these are related: - Gentoo Linux and Gentoo *BSD use different packages in init, but they would use the same package in initscripts, so I'll need to have the virtual keyworded there. - It is possible for a package to provide both /sbin/init and the initscripts function; the example I can think of right now is sys-apps/systemd.
How about "service-manager"?
Alec, that is a good suggestion. Peter, how do you feel about virtual/service-manager?
i'm not sure this is necessary. all the alternative init packages we have replace sysvinit, and that's part of virtual/init. so what if we: - drop the PDEPEND=sys-apps/openrc from sys-apps/baselayout - add virtual/init to base/packages - add sys-apps/openrc to virtual/init as the first entry in the list
Three of our init implementations, freebsd-sbin, runit and sysvinit, are set up to use openrc to manage services. The fourth, systemd, also provides the function to manage services. OpenRC is not an init implementation, so it can't go in virtual/init. Does that make sense?
it'd be trivial to make openrc into an init ;) but fair enough if there are other viable projects actively using openrc with other init's. i didnt think the runit guys did.
