From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
	by finch.gentoo.org with esmtp (Exim 4.60)
	(envelope-from <gentoo-dev+bounces-46892-garchives=archives.gentoo.org@lists.gentoo.org>)
	id 1QoiyH-0002IQ-D1
	for garchives@archives.gentoo.org; Wed, 03 Aug 2011 21:27:21 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id 24CFD21C0AF;
	Wed,  3 Aug 2011 21:27:12 +0000 (UTC)
Received: from mail-iy0-f181.google.com (mail-iy0-f181.google.com [209.85.210.181])
	by pigeon.gentoo.org (Postfix) with ESMTP id 1B47821C081
	for <gentoo-dev@lists.gentoo.org>; Wed,  3 Aug 2011 21:26:38 +0000 (UTC)
Received: by iyb3 with SMTP id 3so553026iyb.40
        for <gentoo-dev@lists.gentoo.org>; Wed, 03 Aug 2011 14:26:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=date:from:to:cc:subject:message-id:references:mime-version
         :content-type:content-disposition:in-reply-to:user-agent;
        bh=DiqpnjJCXTZXEFSv9XNv14IK+62DxyQoP59d3sR/2qA=;
        b=i3CpAyvajL8130pTOeU4mwwuZVgVF8VRKR3d7DxLgXialRgNzW/SEj+egbg9fH+5DX
         KYO/nAxa1aencHNQaymyoRkp96PbpOz52qOb04KGP2WHFCZQchBl9fwd9S/bMUod/yVD
         XRt87E+uAhDE98sVjNvrMJJU8I/AyaQHCkRBk=
Received: by 10.42.189.72 with SMTP id dd8mr3725678icb.100.1312406798664;
        Wed, 03 Aug 2011 14:26:38 -0700 (PDT)
Received: from smtp.gmail.com:587 (c-76-103-93-73.hsd1.ca.comcast.net [76.103.93.73])
        by mx.google.com with ESMTPS id bq3sm489553icb.11.2011.08.03.14.26.34
        (version=TLSv1/SSLv3 cipher=OTHER);
        Wed, 03 Aug 2011 14:26:36 -0700 (PDT)
Received: by smtp.gmail.com:587 (sSMTP sendmail emulation); Wed, 03 Aug 2011 14:26:56 -0700
Date: Wed, 3 Aug 2011 14:26:56 -0700
From: Brian Harring <ferringb@gmail.com>
To: ciaran.mccreesh@googlemail.com
Cc: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Re: POSIX capability in Gentoo
Message-ID: <20110803212656.GA4212@localhost>
References: <4E380EEA.6080505@gentoo.org>
 <20110802155454.5fb24cb4@googlemail.com>
 <4E38123E.90709@gentoo.org>
 <20110802160554.68059c64@googlemail.com>
 <pan.2011.08.02.17.11.27@cox.net>
 <20110802181717.6e156630@googlemail.com>
 <20110802173846.AF04F21C12C@pigeon.gentoo.org>
 <20110802183918.5ef5252c@googlemail.com>
 <20110803002929.GA351@localhost>
 <20110803123421.75bb6bde@googlemail.com>
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20110803123421.75bb6bde@googlemail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Archives-Salt: 
X-Archives-Hash: e17cd4b17a30db5afd60205667549396

On Wed, Aug 03, 2011 at 12:34:21PM +0100, Ciaran McCreesh wrote:
> On Tue, 2 Aug 2011 17:29:29 -0700
> Brian Harring <ferringb@gmail.com> wrote:
> > That's not a "massive change" to vdb behaviour either; file
> > collisions aren't supposed to occur, as such ownership of the file is
> > basically guranteed back to a single package.  Throw in
> > CONFIG_PROTECT for adjusting the behaviour, and you have a far more
> > preferable norm than "lets just leave a shit ton of .pyc/.pyo on the
> > fs".
> 
> It is a massive change, since if the feature is there then people don't
> feel bad about writing lousy pkg_ functions that leave a load
> of .pyc / .pyo files all over the place.

Quoting the good spec:

"The unmerge process removes an installed package's files. It is not 
covered in detail in this specification."

Aka, ebuild's should be written to assume the files they install get 
wiped; there is *zero* mention of mtime, nor could any ebuild rely on 
it and be compliant.

Background as to why we ever relied on mtime- it was a hack to work 
around a bad implementation in portage (treewalk function); it didn't 
actually know if it was replacing or what not, so mtime was what was 
relied on- afaik, that being the sole reason we shoved mtime into 
the vdb also.

At least from the portage standpoint, shifting away from mtime 
reliance was on the radar since '05 and implemented at least 
initially by '06... exact date it was released from a stable branch I 
couldn't tell you, but it's been there a long while.

~brian