This occurs in my openrc system with sys-process/daemontools installed. (Note daemontools is needed for qmail (an mta) to function.) Reproducible: Always Steps to Reproduce: 1. emerge sys-process/daemontools. 2. emerge -av --depclean. 3. DON'T type 'y'. Actual Results: One of the packages emerge proposes to remove is openrc. A careless use of --depclean could leave a system unbootable. Expected Results: --depclean leaves in place all packages required to boot a system, and also those needed for rudimentary maintenance (e.g. nano). (Thanks to Neil Bothwick and Rich Freeman for help in tracking this bug down.) The problem is in virtual/service-manager/service-manager-1.ebuild where virtual/daemontools appears to be deemed an equal of openrc, systemd, runit, etc. At a guess, since daemontools is in @world, --depclean won't remove it, and removes openrc instead. Suggestion: Packages in @system should not be removed by --depclean, unless, possibly, this is specifically requested by the user.
OpenRC is pulled into the system set via virtual/service-manager. If you install sys-process/daemontools the virtual/daemontools will be pulled in which the dependencies of virtual/service-manager. If you need OpenRC, you should add it to your world file.
(In reply to John Helmert III from comment #1) > OpenRC is pulled into the system set via virtual/service-manager. If you > install sys-process/daemontools the virtual/daemontools will be pulled in > which the dependencies of virtual/service-manager. which satisfies the dependencies of..*
The original report was badly worded, this is a real issue. (In reply to John Helmert III from comment #1) > OpenRC is pulled into the system set via virtual/service-manager. If you > install sys-process/daemontools the virtual/daemontools will be pulled in > which the dependencies of virtual/service-manager. If you need OpenRC, you > should add it to your world file. The problem here is that daemontools is djbware and a bunch of ordinary applications depend on it even though daemontools is not actually being used as a service-manager, just an ordinary application dependency. This means that effectively, it's a lie for virtual/service-manager to claim it is satisfiable by daemontools. Nothing to do with portage or changing the behavior of portage.
*** Bug 916244 has been marked as a duplicate of this bug. ***
I maintained net-dns/djbdns for years and I'm pretty sure nobody wants daemontools as a service manager. I've still got app-admin/djbdns-logparse which pulls in daemontools for the tai64nlocal local program used to parse djbdns timestamps. _Technically_ it's a service manager, but we should be realistic here.
See also: commit f1945c8e45319ba99d879a5b8c8c83b0c48f04ed Author: William Hubbs <williamh@gentoo.org> Date: Tue Oct 3 12:56:59 2023 -0500 sys-apps/openrc: use flag changes - drop the prefix use flag since this is not supported. - add an s6 use flag to control installation of s6-linux-init. Signed-off-by: William Hubbs <williamh@gentoo.org> commit e5e49a8d1c2d3cc457505c7ae275bb938bed36d8 Author: William Hubbs <williamh@gentoo.org> Date: Thu Sep 28 17:44:24 2023 -0500 sys-apps/openrc: add sysvinit use flag This flag defaults to on and if i5t is disabled it dropps the dependency on sysvinit. Signed-off-by: William Hubbs <williamh@gentoo.org> which improved the situation too.
(In reply to Michael Orlitzky from comment #5) > I maintained net-dns/djbdns for years and I'm pretty sure nobody wants > daemontools as a service manager. > > I've still got app-admin/djbdns-logparse which pulls in daemontools for the > tai64nlocal local program used to parse djbdns timestamps. > > _Technically_ it's a service manager, but we should be realistic here. I agree with this, we should drop virtual/daemontools dep from virtual/service-manager.
Hi, Thanks for getting some intereset in this bug. Why not add "init" flag to daemontools, which does nothing and defaults to off, and put daemontools[init] as satisfying service-manager? Regards
(In reply to Étienne Buira from comment #8) > Hi, > > Thanks for getting some intereset in this bug. > Why not add "init" flag to daemontools, which does nothing and defaults to > off, and put daemontools[init] as satisfying service-manager? This is a good way to support both use cases if we need to, but at least personally I doubt that anyone is using daemontools as a service manager. If nobody is, then it's easier to simply remove it from the virtual. But I guess we will find out.
It feels like we have quite a bit of support for removing daemontools from virtual/service-manager -- is someone interested in maybe making the relevant change? :) :) :)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8ea70e92f2d736ddd3103780f755413bac97ee05 commit 8ea70e92f2d736ddd3103780f755413bac97ee05 Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2024-10-27 12:03:32 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2024-10-27 12:25:11 +0000 virtual/service-manager: new revision sans virtual/daemontools Daemontools is DJBware that gets pulled in as a dependency of a few other packages. It is also technically a service manager, but one that is not seriously used today. This creates a problem: if users install a package that pulls in daemontools, emerge --depclean now thinks that it is safe to remove OpenRC, because this virtual is satisfied by daemontools instead. In some cases, technically correct is not the best kind of correct, and this is one of those cases. Nobody is using daemontools as a service manager, but a lot of users have complained about their actual service manager getting depcleaned. It's time to drop this. Meanwhile, sys-apps/baselayout-prefix was treecleaned in 2022, so I've cleaned up that dependency as well. Closes: https://bugs.gentoo.org/803878 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> .../service-manager/service-manager-1-r3.ebuild | 26 ++++++++++++++++++++++ 1 file changed, 26 insertions(+)
