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 006581392E8 for ; Sat, 24 Jul 2021 13:47:53 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A6B5BE0B40; Sat, 24 Jul 2021 13:47:45 +0000 (UTC) Received: from mail.muc.de (colin.muc.de [193.149.48.1]) by pigeon.gentoo.org (Postfix) with SMTP id 644DEE0AFF for ; Sat, 24 Jul 2021 13:47:43 +0000 (UTC) Received: (qmail 4067 invoked by uid 3782); 24 Jul 2021 13:47:42 -0000 Received: from acm.muc.de (p4fe157a3.dip0.t-ipconnect.de [79.225.87.163]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 24 Jul 2021 15:47:42 +0200 Received: (qmail 7873 invoked by uid 1000); 24 Jul 2021 13:47:42 -0000 Date: Sat, 24 Jul 2021 13:47:42 +0000 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] --depclean wants to remove openrc. Yikes! Message-ID: References: <20210721221350.4d14da7f@ventiloplattform.tastytea.de> <20210721212705.23179178@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: <20210721212705.23179178@digimed.co.uk> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Archives-Salt: 59685d90-8bd2-4aac-9b0d-286c38b7aeca X-Archives-Hash: 66aa6dc943abaaaf76709f274b26d127 Hello, Neil. On Wed, Jul 21, 2021 at 21:27:05 +0100, Neil Bothwick wrote: > On Wed, 21 Jul 2021 22:13:50 +0200, tastytea wrote: > > > emerge included openrc (the only version of it on my system) in the > > > packages it planned to remove. It was kind enough to give me a > > > warning that this "might" do bad things, but I was somewhat shocked > > > to see it there at all. I might have accidentally typed 'y' instead > > > of 'n'. > > > Maybe the program wants revenge at me executing so seldomly. Or > > > something like that. > Well, it would help if you ran it more often. > > > But now, my question is how can I trust --depclean even a little bit > > > after that? Do I have to go through all the package versions, > > > manually removing the obsolete ones? There are several hundred. :-( > > I'm not sure why it would want to remove openrc, as far as I know it > > should be part of the @system set unless you're on a systemd profile. > It's the first dependency of virtual/system-manager, which in turn is > part of @system. I don't see why it would be removed unless you have > something else installed that satisfies the virtual , such as systemd or > runit. The virtual/service-manager ebuild looks like: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; # Copyright 1999-2021 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 EAPI=7 DESCRIPTION="Virtual for various service managers" SLOT="0" KEYWORDS="~alpha amd64 arm arm64 hppa ~ia64 ~m68k ~mips ppc ppc64 ~riscv ~s390 sparc x86 ~x64-cygwin ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris ~x86-winnt" IUSE="kernel_linux" RDEPEND=" prefix-guest? ( >=sys-apps/baselayout-prefix-2.2 ) !prefix-guest? ( || ( sys-apps/openrc kernel_linux? ( || ( sys-apps/systemd sys-process/runit virtual/daemontools <============================ ) ) ) )" ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Maybe virtual/daemontools is what's doing it. I have sys-process/daemontools-0.76-r8 installed, and this ebuild satisfies virtual/daemontools. However daemontools is NOT (necessarily) an alternative to openrc, but a supplementary utility. (I need it for running a qmail variant.) So, maybe having daemontools in virtual/service-manager is a bug. Also, why is --depclean keeping the _last_ installed package which satisfies a virtual rather than the _first_ package which does? I thought only a single package satisfying a virtual was allowed. Maybe I used some sort of forcing flag to get daemontools installed, I can't remember, and there's nothing about this in my notes. I've got a similar situation with virtual/editor, where I've got vim installed, and --depclean wants to remove nano, but is warning me against it. So in these virtual packages, it seems by default the _last_ mentioned package in a || ( ... ) construct is the one --depclean keeps. It all has the feeling of things not having been properly thought through. > > You can record it in your @world set with `emerge --select --noreplace > > sys-apps/openrc`. That should prevent accidental removals. > It would, but it doesn't address the issue of why portage wants to remove > it. > -- > Neil Bothwick > mandelbug /man'del-buhg/ n. > [from the Mandelbrot set] A > bug whose underlying causes are so complex and obscure as to make > its behavior appear chaotic or even non-deterministic. This term > implies that the speaker thinks it is a Bohr bug, rather than > a heisenbug. See also schroedinbug. -- Alan Mackenzie (Nuremberg, Germany).