From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 2B9F81392E8 for ; Sun, 25 Jul 2021 17:25:26 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C5856E0D98; Sun, 25 Jul 2021 17:25:19 +0000 (UTC) Received: from mail.muc.de (colin.muc.de [193.149.48.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2923EE0D1F for ; Sun, 25 Jul 2021 17:25:18 +0000 (UTC) Received: (qmail 27331 invoked by uid 3782); 25 Jul 2021 17:25:17 -0000 Received: from acm.muc.de (p4fe15d7f.dip0.t-ipconnect.de [79.225.93.127]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 25 Jul 2021 19:25:17 +0200 Received: (qmail 8847 invoked by uid 1000); 25 Jul 2021 17:25:17 -0000 Date: Sun, 25 Jul 2021 17:25:17 +0000 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] --depclean wants to remove openrc. Yikes! Message-ID: References: <20210725100344.34490089@digimed.co.uk> <60FD5869.2050406@youngman.org.uk> <20210725164023.30b6b1ed@digimed.co.uk> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210725164023.30b6b1ed@digimed.co.uk> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Archives-Salt: 1b8dea03-2506-4160-99d0-15a9e43d8e27 X-Archives-Hash: b7aae75bfa8a2e86f3b7e4e7e076f83e 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).