Today one have to manually edit /etc/xinetd.d/XX to enable/disable a service. Would be nice if rc-update/service could manage these services too. One way to do this could be to install files under /etc/xinetd.d/ as hidden(.name) and then have rc-update to create/remove a symlink (tftp -> .tftp)
I think it is better to manually manage xinetd services, especially since the services they control can be run in stand-alone mode with OpenRC scripts. If I were to try to add this, there would be no way for OpenRC to know whether to manage the openrc service or the xinetd service.
(In reply to William Hubbs from comment #1) > I think it is better to manually manage xinetd services, especially Naa, manually is not better :) > since the services they control can be run in stand-alone mode with > OpenRC scripts. Not all services I think, but I don't have which ones in my head. > > If I were to try to add this, there would be no way for OpenRC to know > whether to manage the openrc service or the xinetd service. One could possibly have special xinit service handler instead. manually or not, how do you feel about installing services as .service and the enabling them by creating a symlink service->.service ?
(In reply to Joakim Tjernlund from comment #2) > (In reply to William Hubbs from comment #1) > > I think it is better to manually manage xinetd services, especially > > Naa, manually is not better :) > > > since the services they control can be run in stand-alone mode with > > OpenRC scripts. > > Not all services I think, but I don't have which ones in my head. > > > > > If I were to try to add this, there would be no way for OpenRC to know > > whether to manage the openrc service or the xinetd service. > > One could possibly have special xinit service handler instead. > > manually or not, how do you feel about installing services as > .service and the enabling them by creating a symlink service->.service ? Ping?
(In reply to Joakim Tjernlund from comment #3) as William said, OpenRC is not an inetd, so it doesn't make sense to merge xinetd features into it. i don't even see what you'd gain from it. if you want an eselect module to manage xinetd services, that'd be a different thing.
