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 ) id 1NDeJA-0005kE-A7 for garchives@archives.gentoo.org; Thu, 26 Nov 2009 13:22:52 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8FB6BE0984; Thu, 26 Nov 2009 13:21:52 +0000 (UTC) Received: from mail-yx0-f189.google.com (mail-yx0-f189.google.com [209.85.210.189]) by pigeon.gentoo.org (Postfix) with ESMTP id 67048E0984 for ; Thu, 26 Nov 2009 13:21:52 +0000 (UTC) Received: by yxe27 with SMTP id 27so590311yxe.10 for ; Thu, 26 Nov 2009 05:21:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=Pr9LXJtEkQ0iu+Ji/R/3bOgk7D+UNdl8xvQ47ekp9ZU=; b=s8hBk+j0V1pKUnDomKA8WWcY1BBZbaDd9xu4mUp3MlhrMPt1j5n+4S7eZo+IsAL8i5 /NmRM9dY33qvb+E3L8Qb5SxAFHSgrrvLxV9pKeRZyZ9Y/BDX20hbJ1vb/+AHGPmSHtzj 89ELLTTOuz0Ss3MeBc/9vbfs8Z/RS+2sSQC6g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=XZtHiQh2gOHuXwpN9UveYFZcybrsqXsSlQgUq5I3GFnkpZIMt7RzDbAS1/mjWFQjqb AoQ87oJ/hz4FOnlu8m4xQePLEAFDKQXEF9U2GABGe3RKahikYIYH137325gmMY0Mb6Ph tSFS8AWjGQKYgi2IrfuLL2qXa0rz/KoSxuGz0= Received: by 10.101.18.10 with SMTP id v10mr6108318ani.148.1259241708283; Thu, 26 Nov 2009 05:21:48 -0800 (PST) Received: from smtp.gmail.com (c-98-210-130-131.hsd1.ca.comcast.net [98.210.130.131]) by mx.google.com with ESMTPS id 7sm320306yxd.44.2009.11.26.05.21.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Nov 2009 05:21:46 -0800 (PST) Received: by smtp.gmail.com (sSMTP sendmail emulation); Thu, 26 Nov 2009 05:21:43 -0800 Date: Thu, 26 Nov 2009 05:21:43 -0800 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] mtime preservation Message-ID: <20091126132143.GB6082@hrair> References: <19193.4389.637969.727075@a1i15.kph.uni-mainz.de> <20091119221248.539eedd9@snowmobile> <7c612fc60911191614h5e37c849y50ad217a828fa744@mail.gmail.com> <20091120001820.7274bdf7@snowmobile> <4B07362D.2010108@gentoo.org> <7c612fc60911231049n4a51ddb0u30ae72d8ed93cdec@mail.gmail.com> <20091123231900.GA6085@hrair> <20091124222106.7984b750@snowcone> <20091126012833.GE23443@hrair> <75f3dce80911260441m39885d1codc7f658ec2174a22@mail.gmail.com> 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-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Y7xTucakfITjPcLV" Content-Disposition: inline In-Reply-To: <75f3dce80911260441m39885d1codc7f658ec2174a22@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Archives-Salt: 4b5f4f18-53b3-4fbc-83aa-9b9116d1cef4 X-Archives-Hash: 3f465ae088fb987a8fbb5e371309dc1d --Y7xTucakfITjPcLV Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Potentially just being a tool and taking the bait.. On Thu, Nov 26, 2009 at 12:41:55PM +0000, David Leverton wrote: > 2009/11/26 Brian Harring : > > Why is this one special? =A0Two out of three do this already, and it > > works. >=20 > You mean "two out of three blatently ignored long-standing behaviour > and added a new feature without discussion or an EAPI bump". It was always on the todo to convert portage over to preserving mtime-=20 this long predates PMS and even EAPI. This stretches all the way back to '03/'04. I'll also note that=20 pkgcore from the getgo preserved mtime, back when it was called=20 'portage'. Ahh, the good old days before svn pissed me off enough to=20 move it outside of gentoo. Beyond that, I presume your intention is to stir things up- PMS went=20 out of it's way to explicitly leave it up to the manager if they=20 preserve mtimes. Meaning portage hasn't done anything wrong in=20 changing it's behaviour. It's a bit ironic really. Y'all didn't want mtime in there so it was=20 left unspecified. Now you're complaining that portage changed it's=20 behaviour (2+ years after the fact) as an arguement against adding=20 mtime preservation into the next eapi. > >=A0Paludis doesn't preserve mtime >=20 > You mean "Paludis carefully emulated Portage behaviour, and is now > somehow being blamed for the whole matter, to the extent that people > are trying to use threats (to the effect of 'I'm going to deliberately > break packages for Paludis users") to try to get their way in the > discussion". I mean paludis doesn't preserve mtimes. People aren't going out of=20 their way to break paludis (and claiming so is just trolling). Breakages happen because the common sense assumption devs have=20 (preservation of mtime) aren't actually encoded as a format standard. =20 Further, there are quite a few postinst hacks (and quite a few that=20 don't work all that well) working around the lack of mtime=20 preservation. > > and it's approach to randomly resetting mtimes >=20 > There's nothing random about it. Files' mtimes are reset to the > current time while being merged, just as Portage did for years. Just because portage did something for a few years, does not make it=20 right (this is something the PMS folk have been claiming since day=20 one). So... that arguement is invalidated by your own statements. I label it as 'randomly' due to the fact it's contrary to what ebuild=20 developers expect- it was a flaw when portage was doing it, it's a=20 flaw that paludis does it due to it unnecessarily creating a gotcha=20 for ebuild developers. Most importantly, no one has brought up a=20 single instance of mtime preservation *breaking* things- the only=20 criticism leveled has been ciaranms aesthetic complaints about=20 ca-certificates and older timestamps making their way to the FS. Hence labeling it unnecessarily. Basically, y'all need to provide actual examples of this causing=20 issues- right now the responses are either quite flammable, or lacking=20 in technical arguements. More obstructionist then useful for a=20 technical discourse. ~harring --Y7xTucakfITjPcLV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEARECAAYFAksOgOcACgkQsiLx3HvNzgeFzQCeLJEINtrFkY3b/jSErULvgfP/ YpcAnAybrsH8/63PQ+GgpWvkQuWQ2SNH =WXnc -----END PGP SIGNATURE----- --Y7xTucakfITjPcLV--