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 1NDSx0-0003fI-4T for garchives@archives.gentoo.org; Thu, 26 Nov 2009 01:15:14 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 89060E0A0B; Thu, 26 Nov 2009 01:14:33 +0000 (UTC) Received: from mail-gx0-f224.google.com (mail-gx0-f224.google.com [209.85.217.224]) by pigeon.gentoo.org (Postfix) with ESMTP id 59552E0A0B for ; Thu, 26 Nov 2009 01:14:33 +0000 (UTC) Received: by gxk24 with SMTP id 24so290115gxk.6 for ; Wed, 25 Nov 2009 17:14:33 -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=RZQqLJ1D47W51DV72cxrQTwJrECLBJmDzu8wA9ZrWNM=; b=OSRhVzYZdSpiKXCQsZ0Ap3t/dljBaMaf1fHfp0hJgGySGZxkGu7EAZ+PSFnLI0LcZw pDHtXgZ0Jigg0okuFWoGIu12Mz0pYnIMvgFKi4K6n/ggrTzXOlU8UPp/Jd4jHhu1fk2h zrV6tAuCbM4egH22RFeaa+VccBQ9oEBjMB8G8= 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=t+Ctcp4z9ewx8AG8hUIn206tf2XGzIO8JLTEn9nPKptv+ysuKiSk1n4wOT1s42N4a6 eL1OVssksxJnNk1bMsm/OG1kSRBtPtkrdWx8VxVuiNheMwgX7TvMEdjNDl8C4g61TkbY NZtB4IUd5iDcbFG1fLWrlnM5rwMY2PsJpO8fU= Received: by 10.91.26.31 with SMTP id d31mr629513agj.44.1259198071070; Wed, 25 Nov 2009 17:14:31 -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 7sm103255yxg.32.2009.11.25.17.14.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Nov 2009 17:14:29 -0800 (PST) Received: by smtp.gmail.com (sSMTP sendmail emulation); Wed, 25 Nov 2009 17:14:27 -0800 Date: Wed, 25 Nov 2009 17:14:27 -0800 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] mtime preservation Message-ID: <20091126011427.GD23443@hrair> References: <20091120001820.7274bdf7@snowmobile> <4B07362D.2010108@gentoo.org> <7c612fc60911231049n4a51ddb0u30ae72d8ed93cdec@mail.gmail.com> <7c612fc60911251313i705a182as6cf50402c7829beb@mail.gmail.com> <20091125212718.5deb42f8@snowcone> <20091125221327.324e11fb@snowcone> <19213.46817.620937.656202@a1i15.kph.uni-mainz.de> <20091126001540.08a6e193@snowmobile> <4B0DD08D.8040505@gentoo.org> 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="xHFwDpU9dbj6ez1V" Content-Disposition: inline In-Reply-To: <4B0DD08D.8040505@gentoo.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Archives-Salt: 31968e35-a864-4164-a75c-f9bdf809ed2c X-Archives-Hash: 2470cca290ff3f5f7e0140fd3ea0cdec --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 25, 2009 at 04:49:17PM -0800, Zac Medico wrote: > Ciaran McCreesh wrote: > > On Wed, 25 Nov 2009 23:59:45 +0100 > > Ulrich Mueller wrote: > >> Real examples would be issues like bugs 83877 [1] or 263387 [2]. > >> Nothing that could be easily dismissed or worked around. Both issues > >> are fixed with Portage since a long time. > >=20 > > Yes, those are examples of packages relying upon something that is > > undefined behaviour, and that behaves differently depending upon the > > Portage version you use. > >=20 > >> I don't know of any example where non-preservation of nanosecond > >> timestamps would cause problems. > >=20 > > Not non-preservation. Partial and inconsistent corruption. >=20 > Wouldn't "loss of precision" be a more accurate description? Of the > known packages which require timestamp preservation, do any of them > use sub-second precision in their timestamp comparisons? This discussion in generall is daft. No package can rely on=20 nanonsecond resolution for installation because the most common FS out=20 there (ext3) does *second* level resolution only. As such, I can=20 pretty much gurantee there is *zero* packages out there that require=20 nanosecond resolution for installation. It's an academic discussion, and pointless. We don't mandate the=20 filesystems PMS implementations are run on- as such we cannot make a=20 gurantee to ebuilds that nanosecond resolution is available. It's=20 daft to encode in the spec NS resolution when it's essentially=20 impossible to gurantee it- I'm honestly not sure why we're having this=20 discussion beyond the "python sucks" angle. ~brian --xHFwDpU9dbj6ez1V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEARECAAYFAksN1nMACgkQsiLx3HvNzgdoRwCg1tSv3/fMhYeeV1Bu6TJ8DqRu wFIAoNiL44ecGw59hKvopdWin2TJBvTw =EQYR -----END PGP SIGNATURE----- --xHFwDpU9dbj6ez1V--