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 3921A1396D9 for ; Sat, 11 Nov 2017 17:31:31 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D2BEFE1139; Sat, 11 Nov 2017 17:31:25 +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 82810E1134 for ; Sat, 11 Nov 2017 17:31:24 +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 0028333C770 for ; Sat, 11 Nov 2017 17:31:22 +0000 (UTC) Subject: Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer To: gentoo-dev@lists.gentoo.org References: <05c08f65-3cf6-67f4-621e-cf210fe2a82c@gentoo.org> <1510387105.1210.2.camel@gentoo.org> From: Michael Orlitzky Message-ID: Date: Sat, 11 Nov 2017 12:31:15 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.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: <1510387105.1210.2.camel@gentoo.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Archives-Salt: 7b7039ec-23c2-44e2-9690-c8db43166d7d X-Archives-Hash: a20ce7fc43dbac738fa412ba7c07db1f On 11/11/2017 02:58 AM, Michał Górny wrote: >> >> Certainly "keepdir" will make the directory non-empty, but with the >> additional (unwanted) side-effect that the directory won't be removed >> when the package is uninstalled. > > Wrong. It creates a dotfile inside it, and removes it along with it. Gotcha, I never tested my assumption that keepdir would keep the dir =P FWIW, `man 5 ebuild` says keepdir "Tells portage to leave directories behind..." It's not at all apparent that the "left behind" refers to the unmerge of some other, unrelated, package. >> a) When would you want to use keepdir? > > Because it works. Makes sense now, thanks. >> and a meta-question, >> >> c) Seriously, empty directories are undefined behavior? > > ...and how could they be defined if a directory can be installed by > multiple packages and has no explicit ownership? I see the problem, but the package manager knows which packages are using a given directory. (Portage does, and it is at least easy to record that information.) Empty directories could be installed normally, and then during an unmerge, the package manager could check to see if the empty directory is used by any package. If it is, leave it -- if not, remove it. You might object that this would slow down the unmerge process, but a clever lookup scheme would let you map directory names to packages quickly. In fact, such a lookup scheme is already implemented in the filesystem itself, leading me full circle to the following idea: if the package manager is about to install an empty directory, it could create the ".keep" file itself. Then "ls -a $dir" is your lookup function that determines whether or not a directory is in use by a package. Having the package manager handle empty directories solves two problems, 1) Use of "keepdir" is inconsistent, because portage is happy to let you create an empty directory without it (even though that operation is illegal). 2) The build systems of many packages will create empty directories during "make install", and it's unreasonable to expect developers to "keepdir" them all. Essentially,we have two commands to create a directory, "dodir" and "do-empty-dir" (which we call "keepdir"). The latter is only necessary due to an implementation detail, so it doesn't belong in the user interface -- the PM should figure out what to do. As far as the actual implementation goes, I'm not sure that automatically-generated ".keep" files are better than having the package manager maintain its own database. The latter would be more complex, but would avoid littering everyone's filesystems with ".keep" files.