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 1NBGwY-0005Pc-Rt for garchives@archives.gentoo.org; Fri, 20 Nov 2009 00:01:43 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7ACECE0DC0 for ; Fri, 20 Nov 2009 00:01:42 +0000 (UTC) Received: from mail-bw0-f215.google.com (mail-bw0-f215.google.com [209.85.218.215]) by pigeon.gentoo.org (Postfix) with ESMTP id 0A304E0F34 for ; Thu, 19 Nov 2009 22:12:57 +0000 (UTC) Received: by bwz7 with SMTP id 7so3125074bwz.26 for ; Thu, 19 Nov 2009 14:12:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=1wBUqLWO/FGtU+1NUYuINHEak9TllW167Ewa8wzWn+4=; b=NL0KOQeLqkj+UjKL6SkSFBifAolTvrQ7tjb984rphZB7tYYnih02SfcM8YIVHiFiTO ddfqZ3URLk7ZZA9tnoHQk4aCuoIegHSo4eZ2N6rN/hLUad9mDkTZA/ovAQcikTs6cfF0 DTdOhUyMVo3fWmyGEWR06DlQXmsd1wBwAtD20= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=LxKC/4phkuIEIvu9UpM+fuOGj3IycGdbwoT9g9aDhGC1nq4IPJheLvp1TfP19KMkgm 7Ld0oL3V79SWVpuRmHOu+Im2ctHvGbXcx+P/ARuYePXMKOnpCUDA8Lp8nLQ0NVEDtL9B yMai69210xUlf2+esWPkWw8EQHJxwi+1YM7FI= Received: by 10.216.86.9 with SMTP id v9mr173033wee.148.1258668776663; Thu, 19 Nov 2009 14:12:56 -0800 (PST) Received: from snowmobile (92-235-187-79.cable.ubr18.sgyl.blueyonder.co.uk [92.235.187.79]) by mx.google.com with ESMTPS id q9sm1598350gve.15.2009.11.19.14.12.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Nov 2009 14:12:56 -0800 (PST) Date: Thu, 19 Nov 2009 22:12:48 +0000 From: Ciaran McCreesh To: Ulrich Mueller Cc: gentoo-council@lists.gentoo.org Subject: Re: [gentoo-council] mtime preservation Message-ID: <20091119221248.539eedd9@snowmobile> In-Reply-To: <19193.4389.637969.727075@a1i15.kph.uni-mainz.de> References: <19184.25176.380022.392451@a1i15.kph.uni-mainz.de> <20091103180632.0eb8e26c@snowcone> <19185.39090.798573.758417@a1i15.kph.uni-mainz.de> <20091104152835.369e3e18@snowcone> <19186.42949.760878.199957@a1i15.kph.uni-mainz.de> <20091108191439.3fcee79d@snowcone> <7c612fc60911090718y144319f5lc9827a5e2e153c2@mail.gmail.com> <20091109153429.502e272f@snowcone> <19193.4389.637969.727075@a1i15.kph.uni-mainz.de> X-Mailer: Claws Mail 3.7.3 (GTK+ 2.16.5; i686-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-council@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/553V+hl9=cP4hZF+pru+CzM"; protocol="application/pgp-signature" X-Archives-Salt: d66359ac-01ed-4cff-b04e-804b20b504d6 X-Archives-Hash: a3ef4f3674f887dbe1f6469513026eb2 --Sig_/553V+hl9=cP4hZF+pru+CzM Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 10 Nov 2009 08:07:17 +0100 Ulrich Mueller wrote: > ,---- > | The package manager must preserve modification times of regular > files. | This includes files being compressed before merging. > Exceptions to | this are: > `---- >=20 > Now we need to enumerate the exceptions: >=20 > ,---- > | * files newly created by the package manager, > `---- >=20 > This will cover splitdebug, for example. (And please don't tell me > that the wording is flawed because the PM could save a file's contents > in some buffer, then delete the file and create it newly. This would > be as unreasonable as the rot-13 example.) Funnily enough... objcopy does its own fancy things with utimes. Last time I looked it wasn't sub-second aware, though. > ,---- > | * binary object files being stripped of symbols. > `---- > > Anything else missing from above list? man pages, info pages, things covered by ecompress, arbitrary documentation, any source code file, probably some others. > > (thus preventing reasonable-looking future changes), [...] >=20 > I don't get the point here. For any future change not covered by the > list of exceptions, the PM would have to preserve mtime, in spite of > modifying the file. Why would this prevent doing the change? Preserving mtime isn't always the right thing to do, though. If the package manager does something that would invalidate caches, you don't want it to do so in a way that won't be noticed. Also, back on the subject of sub-second resolution mtimes... Python doesn't support them properly thanks to some utter brain damage from its designers [1]. Files will end up with corrupted sub-second mtimes if Python is used to set those times, which can again lead to broken caches. But since not everything Portage merges does use Python to set sub-second mtimes, this will result in any cache that starts looking at sub-second resolution mtimes (which will happen -- POSIX considers the non-sub-second functions deprecated) seeing a mix of valid and subtly corrupted timestamps. I honestly don't think we should be going anywhere with this until Portage is using a mechanism that guarantees correct sub-second resolution preservation in all cases. [1]: http://ciaranm.wordpress.com/2009/11/15/this-week-in-python-stupidity-= os-stat-os-utime-and-sub-second-timestamps/ --=20 Ciaran McCreesh --Sig_/553V+hl9=cP4hZF+pru+CzM Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAksFwuQACgkQ96zL6DUtXhGVWwCgjHOOatm+If2R9Qth9mcwOR9V x6IAoJLM/oaZf+w4U+tQQPAWy1AwEliV =g91F -----END PGP SIGNATURE----- --Sig_/553V+hl9=cP4hZF+pru+CzM--