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 F010E1396D9 for ; Sat, 11 Nov 2017 19:26:58 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A8C4FE115C; Sat, 11 Nov 2017 19:26:52 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 55A0DE114D for ; Sat, 11 Nov 2017 19:26:52 +0000 (UTC) Received: from pomiot (d202-252.icpnet.pl [109.173.202.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 8DB05335DEF; Sat, 11 Nov 2017 19:26:50 +0000 (UTC) Message-ID: <1510428406.2446.2.camel@gentoo.org> Subject: Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Date: Sat, 11 Nov 2017 20:26:46 +0100 In-Reply-To: References: <05c08f65-3cf6-67f4-621e-cf210fe2a82c@gentoo.org> <1510387105.1210.2.camel@gentoo.org> Organization: Gentoo Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.5 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 Content-Transfer-Encoding: 8bit X-Archives-Salt: 09e5e456-cf31-4996-897e-fd0b51c108a6 X-Archives-Hash: 734dd14b7c99139c2007f2e42b27a2f5 W dniu sob, 11.11.2017 o godzinie 12∶31 -0500, użytkownik Michael Orlitzky napisał: > > > 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. What about a directory that is installed empty by multiple different packages, and non-empty by some other packages? > 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). It is not. It is just not guaranteed to be meaningful. > > 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. Not all of those directories are really meaningful. > 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. Do you care enough to spec this properly, introduce EAPI-conditional behavior for it and prepare patches for the package managers? -- Best regards, Michał Górny