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 6A6071392E8 for ; Sat, 24 Jul 2021 21:01:45 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BD24BE0A7E; Sat, 24 Jul 2021 21:01:38 +0000 (UTC) Received: from mail.muc.de (colin.muc.de [193.149.48.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0E0F0E09CE for ; Sat, 24 Jul 2021 21:01:37 +0000 (UTC) Received: (qmail 91445 invoked by uid 3782); 24 Jul 2021 21:01:36 -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 23:01:36 +0200 Received: (qmail 23211 invoked by uid 1000); 24 Jul 2021 21:01:34 -0000 Date: Sat, 24 Jul 2021 21:01:34 +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: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Archives-Salt: 5ab2d5a2-fa33-4a00-9671-f899223b9db8 X-Archives-Hash: ad6de379fc44ecbfed8bd7e5a8e706ae Hello again, Rich. On Sat, Jul 24, 2021 at 10:58:55 -0400, Rich Freeman wrote: > On Sat, Jul 24, 2021 at 10:46 AM Alan Mackenzie wrote: > > On Sat, Jul 24, 2021 at 10:14:20 -0400, Rich Freeman wrote: > > > On Sat, Jul 24, 2021 at 9:47 AM Alan Mackenzie wrote: > > > > 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. > > > I'm not sure what the default is - most likely PMS just requires that > > > one of them be kept. > > PMS? Part of emerge? > Package Manager Specification. Specifically: > https://projects.gentoo.org/pms/8/pms.html#x1-760008.2.3 Ah, thanks! > All it requires is that one be present. Portage can use whatever > behavior it wishes to decide which to keep (assuming all installed > packages have their deps). > > It seems it's insisting on removing all packages but one which satisfy a > > virtual. Maybe that is unwise, and it should keep _all_ such packages > > which are currently installed. > Well, the whole point of an any-of dependency is to only require one > of them. Why force packages to stick around if they aren't needed? I would say all packages in @system _are_ needed, unless the user explicitly says otherwise. > Now, whether daemontools actually should satisfy the dependency I > don't want to comment on without doing more research. Surely though > there is little point in having openrc and systemd and runit on the > same system unless the user explicitly wants this (and if they do they > can just stick them in @world). The user might be switching between them, doing comparisons. (No, I don't know if this is practical.) I don't know either whether it's practical to boot Gentoo with just daemontools. But there are use cases which require both openrc and daemontools on the same system, so there's something not quite right about the service-manager ebuild, or emerge. > > I'm considering submitting a bug to bugs.gentoo.org, requesting that > > _all_ installed packages satisfying a virtual get kept. There is surely > > something wrong when somebody who just wants to be a user (me) has to > > read .ebuild files to get normal things done. > I'd be shocked if that went anywhere. I'd think the better solution > would be to have some kind of USE flag that tells daemontools whether > it is used as an actual service manager or not, though that has its > own issues (changing that state shouldn't require rebuilds/etc, but it > would). I think that would be solving the wrong problem. The fact is, it is easy, far too easy, to shoot yourself in the foot here. As well as openrc, --depclean also wanted to remove nano (the editor) for the same reason. That might be serious for some people. I have, in fact, submitted a bug on the "shoot yourself in the foot" problem. So far it's got one reply which (possibly wilfully) misunderstood the intent of the report, and said, much like you did "add daemontools to @world and the problem's solved". Maybe the answer is to regard --depclean as a tool for experts only, since it is capable in ordinary innocent use of rendering a system unusable. > In any case, you probably should have a chat with the daemontools > maintainer. I doubt the portage team would consider doing something > like this as some kind of universal policy. It would impact hundreds > of things that have any-of dependencies. OK. The suggestion I made in my bug report was that @system packages should be protected, much like @world packages are already. I don't see the rationale in protecting @world, but not the more important @system. > -- > Rich -- Alan Mackenzie (Nuremberg, Germany).