Re: [gentoo-user] --depclean wants to remove openrc. Yikes!

[Alan Mackenzie <acm@muc.de>]

Hello, Neil.

On Sun, Jul 25, 2021 at 16:40:23 +0100, Neil Bothwick wrote:
> On Sun, 25 Jul 2021 13:43:46 +0000, Alan Mackenzie wrote:

> > > It may be critical for *your* system ... :-)  

> > Just as systemd is for your system.  If you'd installed daemontools you
> > would also have come within a keystroke of destroying your system, just
> > as I did, on attempting emerge --depclean.  You would have received no
> > warning of any kind on installing the package, and there would be no
> > documentation brought to your attention about the potential catastrophe.

> This is a valid point, that appears to have been obscured by some of the
> discussions about the cause. As to whether it would render the system
> unbootable, I have no idea, would daemontools have taken care of that.

And this is the main point of my complaint - the surprise, the shock, and
the innocence (as in opposite of guilty, not of wordly-wise) of the
victims.  They have done nothing but installing a package in the normal
way.  daemontools can only boot a system if it's been configured to do
so.  That involves writing entries into /etc/inittab.

The number of people who would lose their systems by this mechanism is
likely very small, but that loss would probably involve a
re-installation.  I mean all a victim has to go on is the fact that his
machine won't boot, combined with a memory of having run emerge
--depclean the night before.

My guess (for which I have little basis) would be that daemontools is
used more as part of the various qmail variants rather than as the prime
init system.  I don't recall anybody on this list using d. rather than o.
or s. as their main init system.  In fact, I wasn't even aware it was
possible, before looking it up on Wikipedia this afternoon.

> It seems that Rich's suggestion has the most merit, add a USE flag to
> daemontools to indicate that it is intended to be your service manager,
> and have the virtual require that flag. Yes, it would require a
> one-off rebuild of daemontools for everyone with it installed, but the
> potential for breakage would be removed.

Another idea I had today is to have two packages, daemontools and
daemontools-init, which would be identical, apart from the fact that only
the second of these would satisfy virtual/service-manager.

> If I had to allocate blame for this, I would say it is the virtual that
> is the cause of the problem. With the current setup, unmerging openrc is
> the only way for depclean to deal with it when you have daemontools in
> @world.

I can't help feeling that maybe portage has become too complicated.

> -- 
> Neil Bothwick

> Top Oxymorons Number 41: Good grief

-- 
Alan Mackenzie (Nuremberg, Germany).