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 B4BBB1382C5 for ; Fri, 27 Apr 2018 16:29:14 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8A433E081B; Fri, 27 Apr 2018 16:29:08 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 3D005E07EE for ; Fri, 27 Apr 2018 16:29:07 +0000 (UTC) Received: from mail-ot0-f175.google.com (mail-ot0-f175.google.com [74.125.82.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: floppym) by smtp.gentoo.org (Postfix) with ESMTPSA id D7591335C63 for ; Fri, 27 Apr 2018 16:29:05 +0000 (UTC) Received: by mail-ot0-f175.google.com with SMTP id l22-v6so2689351otj.0 for ; Fri, 27 Apr 2018 09:29:05 -0700 (PDT) X-Gm-Message-State: ALQs6tDQFFpDwrWy+d/w05nzvRNnJwoPAf7tvtH7M7d6GdjOHvABoQuv BwfG7FKFU13ezeJ0dlRjaTbSenONoGA9nq77O08= X-Google-Smtp-Source: AB8JxZpxjfZhEk8MsNk3J/E97AQ1rJttGq/df6UJusIvX0OSSs8kHoJKvbtvOhsgrcZzJfxcQjG63jzQdAeum40EEr0= X-Received: by 2002:a9d:5e06:: with SMTP id d6-v6mr1796954oti.148.1524846543944; Fri, 27 Apr 2018 09:29:03 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.74.78.199 with HTTP; Fri, 27 Apr 2018 09:28:43 -0700 (PDT) In-Reply-To: <20180427154501.GA2144@whubbs1.gaikai.biz> References: <20180425192029.GA25356@whubbs1.gaikai.biz> <20180426163351.GA29521@whubbs1.gaikai.biz> <20180426200853.GA30322@whubbs1.gaikai.biz> <20180427183411.4273dcdc@katipo2.lan> <0a2f4f29-0a8a-c00e-430c-cdd0089bdb30@gentoo.org> <20180427154501.GA2144@whubbs1.gaikai.biz> From: Mike Gilbert Date: Fri, 27 Apr 2018 12:28:43 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [gentoo-dev] rfc: virtual/init for init process To: Gentoo Dev Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 66847951-7a7b-47fd-8898-c431d056e6e1 X-Archives-Hash: 7d67b5c758e76042e1d8148305c83b99 On Fri, Apr 27, 2018 at 11:45 AM, William Hubbs wrote: > On Fri, Apr 27, 2018 at 12:48:09AM -0700, Zac Medico wrote: >> On 04/26/2018 11:34 PM, Kent Fredric wrote: >> > On Thu, 26 Apr 2018 13:35:15 -0700 >> > Zac Medico wrote: >> > >> >> emerge --depclean, resulting in an unbootable system. Just say-in. >> > >> > And depclean being very verbose doesn't do many favours here either. >> > >> > ( I regularly do >500 package depcleans and spotting things that aren't meant to be >> > culled amongst that list is a bit of a challenge )> >> >> At least for system packages, it will show a warning like the one shown >> here: >> >> https://bugs.gentoo.org/642484#c0 >> >> Hopefully that message helps those that are paying enough attention. >> What can we do for those that overlook the warning message, other than >> give them some rescue instructions for making their system boot again? > > Another option suggested to me was to add a use flag to OpenRC that > pulls in a dependency on virtual/init instead of adding virtual/init to > @system. The suggestion originally was to add it to rdepend, but that > doesn't feel right to me since openrc really doesn't have a runtime > dependency on init, so I'm thinking something like this: > > IUSE="... +separate-init" > > PDEPEND=" > ... > separate-init? ( virtual/init )" > > Thoughts? RDEPEND and PDEPEND have essentially the same meaning when there are no cycles in the dependency graph. The devmanual suggests that PDEPEND should only be used to avoid cyclic dependencies. I don't see any reason to prefer PDEPEND over RDEPEND here, and I don't understand why that would "feel" better. It effectively gets treated as a runtime dependency either way.