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 1ND5ZB-0006Zz-PD for garchives@archives.gentoo.org; Wed, 25 Nov 2009 00:17:06 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5F755E0B86 for ; Wed, 25 Nov 2009 00:17:05 +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 1E52FE0740 for ; Tue, 24 Nov 2009 22:21:13 +0000 (UTC) Received: by bwz7 with SMTP id 7so518586bwz.26 for ; Tue, 24 Nov 2009 14:21:13 -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:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=6l8gJSZjh89thvUa5uXlk6trjdEQcWjDb9o6KzoXSb8=; b=Cal0Cx5qWkdvu8ZAywmf6OyPLjiil5k/WbWezIZklguX2CoZ8rpUR368rCJhJkbXzR wOzyv8Vwqi0x5Obwe/rRC46Zg8up3Htl2AL3xKBMj2YpEr8uYgs+PB7RZ3eJeQkF0QwN UzJZSjONQjfd2jMhKa4BOWk9TH9x/dEbyV7pg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=NyTbAFKgWOUcnRAR9Z7qMTgJ75Oij+58ID7NhfMXOfhsbJYKLMDvYpqJlHdvCGDe50 XnlRBusHfPFDdqci0seHjNuduuFnRVDlq/kDk1HsYZ0YPpiay1z+xMomJw/vTxk1dANk kkAf4HQ8faTLQ2pr0Ng3QhYMQlM5/uTEuL8cY= Received: by 10.204.154.142 with SMTP id o14mr6663976bkw.125.1259101273289; Tue, 24 Nov 2009 14:21:13 -0800 (PST) Received: from snowcone (92-235-187-79.cable.ubr18.sgyl.blueyonder.co.uk [92.235.187.79]) by mx.google.com with ESMTPS id e17sm7786749fke.23.2009.11.24.14.21.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Nov 2009 14:21:12 -0800 (PST) Date: Tue, 24 Nov 2009 22:21:06 +0000 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] mtime preservation Message-ID: <20091124222106.7984b750@snowcone> In-Reply-To: <20091123231900.GA6085@hrair> References: <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> <20091119221248.539eedd9@snowmobile> <7c612fc60911191614h5e37c849y50ad217a828fa744@mail.gmail.com> <20091120001820.7274bdf7@snowmobile> <4B07362D.2010108@gentoo.org> <7c612fc60911231049n4a51ddb0u30ae72d8ed93cdec@mail.gmail.com> <20091123231900.GA6085@hrair> X-Mailer: Claws Mail 3.7.3 (GTK+ 2.16.6; x86_64-pc-linux-gnu) 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; boundary="Sig_/Xh=QILmGczqAtLShe6r+kCV"; protocol="application/pgp-signature" X-Archives-Salt: 8ef85fbe-9fb8-4213-945a-1f6cabb00b42 X-Archives-Hash: eab9d4a8c6fa313a61f253d0725604fb --Sig_/Xh=QILmGczqAtLShe6r+kCV Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 23 Nov 2009 15:19:00 -0800 Brian Harring wrote: > Someone mind explaining to me why we're making mtime preservation so=20 > nasty? Having to enumerate every pathway that requires mtime=20 > preservation is pretty arduous for the ebuild dev, meaning it's=20 > unlikely they'll get it right, leading to bugs. It's not in the least bit nasty. It's requiring people to be explicit about special requirements. > The thing I'm not understanding here is that pkgcore since day one > has preserved mtime- I've yet to see any complaints about that nor > any issues caused by it. Portage shifted over a year or two back, > same thing, haven't heard complaints. You can't have been listening very hard, then. The complaint is that it results in files with dumb mtimes being merged to /. > I know it won't fly, but realistically stating "the package manager=20 > must preserve mtime- if there are instances where it does not (due to=20 > some feature, perhaps splitdebug or some form of compression) it is=20 > the package managers responsibility to ensure this does not break the=20 > ebuilds resultant merge/runtime invocation". >=20 > Via such wording an exemption is created and it's made clear it's the=20 > managers responsibility to keep things playing nice... if the manager=20 > can't do that, then the feature/functionality that is changing the=20 > mtime (resulting in the pkg on disk failing) must be fixed or=20 > disabled. >=20 > The nice thing about this wording is that it basically matches what=20 > the case is now, and what has worked for quite a few years. Wording such as that just isn't suitable for a specification. It requires implementers to guess what future ebuilds are going to rely upon (and ebuilds regularly do rely upon weird quirks), and makes it impossible to produce a package manager that can be shown to be compliant. > > In both cases nanosecond resolution may be required and is a problem > > due to python. The following workaround can be used until the > > nanosecond issue is fixed in python: >=20 > It'd be nice if someone enumerated merge scenarios where nanosecond=20 > resolution is actually required. Seems like a white elephant to me,=20 > especially in combination w/ the fact that the target fs may not=20 > support nanosecond. POSIX considers several of the non-nanosecond resolution calls to be deprecated. Going "la la la I can't hear you!" because Python happens to have utterly screwed this up is just going to lead to problems when programs start using sub-second validity checks -- 'make' already does, and it's given rise to various build-directory-related issues. > Basically, if it's required the manager support nanosecond resolution=20 > for merging, ebuilds must be able to rely on that- end result, any=20 > merging to FS's that do not support nanosecond (this includes the=20 > intermediate ${D}) are no longer supported. Unless I'm missing=20 > something, iso-9660 doesn't look to support nanosecond resolution. =20 > Beyond that, does cramfs/squashfs? If not, taking this to the=20 > logical conclusion the livecds aren't technically supported as a > merge environment. No, we're after a requirement that the package manager must not screw up nanosecond-resolution timestamps, and must not partially preserve and partially not preserve them. > > "Alternatively, we could simply make portage spawn the mv binary > > whenever rename fails (it fails when the source and destination are > > on different devices). Although it's relatively slow, it should > > solve the problem." >=20 > Yeah... no. Slowing down the main manager for a thereotical edge > case doesn't seem particularly useful to me ;) ...or you could just fix Python. --=20 Ciaran McCreesh --Sig_/Xh=QILmGczqAtLShe6r+kCV Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAksMXFUACgkQ96zL6DUtXhFnsQCgovNQqTwf3jCYGZm95U9/YQCm apgAn13Gt9WgakN+JeI45jzWJXtcGuNd =Ngym -----END PGP SIGNATURE----- --Sig_/Xh=QILmGczqAtLShe6r+kCV--