From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1JtYZ3-0002Oc-Q5 for garchives@archives.gentoo.org; Wed, 07 May 2008 01:35:26 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EBF2BE039F; Wed, 7 May 2008 01:35:23 +0000 (UTC) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by pigeon.gentoo.org (Postfix) with ESMTP id CE7FCE039F for ; Wed, 7 May 2008 01:35:23 +0000 (UTC) Received: by py-out-1112.google.com with SMTP id w53so104485pyg.25 for ; Tue, 06 May 2008 18:35:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=PrTOIbgE+JxYjP3cryhvfgoqeW/c9ogODw76zTJkkpY=; b=YL4n/d/KVCuzRdTwHoclWyycEoWMxQchy78F2Y8iRY+4m0y0IjrDAfrQYsWBxvQSTzv+kgxR03WLka+m+a1qLK6bDf97MsTAcBOVCq4EDSGOLT5s89LjTlTd0sca5ttna8pkdcHuimknbuAFRhODHyKbKNBN8qEYloG+SDG+GXU= 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=psHLaMxuYjL0GQpg7yVv0CBSrNZNpIEMtZRP01RzNQHn9FmVk8QXxkl9x4JBBJckS9OD6pEEfxHTgTUNOldo1GWcNPcrUhaL7BKvNfmn8O0s39SZs1GphCEKIoqM+OLiyDsGw8WEgil73NBTGf3K/aCdGdc9ozayhYojb1S37ag= Received: by 10.114.39.16 with SMTP id m16mr1350000wam.146.1210124123330; Tue, 06 May 2008 18:35:23 -0700 (PDT) Received: from seldon ( [208.68.109.97]) by mx.google.com with ESMTPS id n22sm2751953pof.3.2008.05.06.18.35.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 06 May 2008 18:35:22 -0700 (PDT) Date: Tue, 6 May 2008 18:35:18 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] preserving mtimes Message-ID: <20080507013518.GB6862@seldon.metaweb.com> References: <4820DF4C.7000801@gentoo.org> <20080507015219.100c877f@snowcone> 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="envbJBWh7q8WU6mo" Content-Disposition: inline In-Reply-To: <20080507015219.100c877f@snowcone> User-Agent: Mutt/1.5.13 (2006-08-11) X-Archives-Salt: d578736b-bd13-4aed-89e9-d4e9766ea828 X-Archives-Hash: 0004f5dc024a863e7fe35318d1cd23dc --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 07, 2008 at 01:52:19AM +0100, Ciaran McCreesh wrote: > On Wed, 07 May 2008 00:44:28 +0200 > "Marijn Schouten (hkBst)" wrote: > > and I think that would be the correct thing to do, but either way I'd > > like PMS to specify what should happen wrt to mtimes, so that I can > > rely on that. >=20 > PMS makes no guarantee as to what happens with mtimes, which means you > can't rely upon things happening one way or the other. This is > deliberate -- preserving mtimes leads to all kinds of weirdness on > packages that are generated from a raw tar file rather than from a > build system. I'd be curious what weirdness you're referring to, since pkgcore has=20 preserved mtime from the get go. Yet to see a single issue from it, although *I* could think of a few=20 instances where it would be problematic- that said, those pkgs already=20 do postinst resetting of mtime to work around portage/paludis=20 resetting mtime, so those issues doesn't appear. > > Current work-around is tarring up and untarring to preserve mtimes. >=20 > That's not really any good either. The proper solution would be to fix > whatever it is that's mtime-sensitive. That's not exactly much of a solution; simplest example, that results=20 in python.eclass:python_mod_compile, invoked during postinst to reset=20 the cached bytecode mtimes (essentially). Aside from this being=20 uncontrolled/untracked access to the live fs, this slows down merges=20 due to redundant work. Finally, it also trashes the chksums that the manager records upon=20 merging to the fs- so an mtime/chksum based unmerger can/will orphan=20 those files. Frankly, the mtime issue keeps rearing its head and needs killing-=20 it's been an issue for near 4 years even, back in the OSX days we had=20 to rewrite .a TOC's since the linker was mtime aware. See no reason to preserve this misfeature. Can't comment on paludis,=20 but it shouldn't be an issue for portage to make the leap from what=20 I've seen source wise. ~harring --envbJBWh7q8WU6mo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFIIQdWsiLx3HvNzgcRAjtCAKC7tRHwYWinN7ekM4nn/iXJWBbtngCeJWoz Zc/XjQvUsNisKur/0s6z8ZM= =7Db0 -----END PGP SIGNATURE----- --envbJBWh7q8WU6mo-- -- gentoo-dev@lists.gentoo.org mailing list