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 9245E1382C5 for ; Thu, 29 Mar 2018 16:24:48 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 47A25E0950; Thu, 29 Mar 2018 16:24:43 +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 E0771E0905 for ; Thu, 29 Mar 2018 16:24:42 +0000 (UTC) Received: from [192.168.1.100] (c-98-218-46-55.hsd1.md.comcast.net [98.218.46.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mjo) by smtp.gentoo.org (Postfix) with ESMTPSA id 5AB74335D1E for ; Thu, 29 Mar 2018 16:24:41 +0000 (UTC) Subject: Re: [gentoo-dev] rfc: empty directories in ${D} To: gentoo-dev@lists.gentoo.org References: <20180329143952.GA10523@linux1.home> <1522334871.1006.23.camel@gentoo.org> <20180329155710.GA15777@whubbs1.gaikai.biz> From: Michael Orlitzky Message-ID: Date: Thu, 29 Mar 2018 12:24:38 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 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 In-Reply-To: <20180329155710.GA15777@whubbs1.gaikai.biz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Archives-Salt: 718d7651-3e5f-457a-83b6-2e14d22cd86a X-Archives-Hash: 72491d73efa5f139318880891a05ae00 On 03/29/2018 11:57 AM, William Hubbs wrote: >> >> The PMS says that empty directories are undefined, so the portage >> behavior of installing them and leaving them alone leads to >> incompatibilities. Ebuilds rely on the portage behavior, and if another >> PM (within its rights) deletes them, then the package breaks with the >> non-portage PM. > > Maybe so, but you just made the argument for doing nothing different in > current eapis and proposing stripping empty directories in eapi 7. > However, this should be stripping empty directories combined with > failing the emerge. If we strip them only in EAPI=7, then that still leaves all of these packages broken with respect to the PMS in the other EAPIs. Stripping the empty directories isn't my favorite approach, but leaving things broken looks bad on paper too.