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 1NCjE4-0007ok-OG for garchives@archives.gentoo.org; Tue, 24 Nov 2009 00:25:49 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5EEE5E0A6A for ; Tue, 24 Nov 2009 00:25:48 +0000 (UTC) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by pigeon.gentoo.org (Postfix) with ESMTP id B6C5EE072C for ; Mon, 23 Nov 2009 23:20:05 +0000 (UTC) Received: by gxk28 with SMTP id 28so5416251gxk.9 for ; Mon, 23 Nov 2009 15:20:05 -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=e9ey9/7RRcw0fo9JmLLETXDIdAfL2HQVotx5e+goNA4=; b=Dgg93CdQHK8wn6SdKha5chOZLxSlvs+fbbWhkrwvLUQSpiUt7w2VF7SJaAl2b8AkV2 xtqvShBFgpvLidlR4fhkD6MC4Y8Yp1HkhRlCHmhkuc5xb40/htBbEQW/M66fOUFlvRvS mBpdoOwSEliGai0UqYqyEFgy/G6YGf5t5fjgg= 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=ZXU0BCS9tSL/A+GIIz+nlSgc/aw9xniTyfMG3pZCj/ARfCFPxzA3Br5uQo37ezC3RM yqA49CxtXz7NpVzPs2tCAXb6gTlN+eBHB7ylEGHnnmuJgPHS2gV3y9a3XGGRQcljyd7M 0SNswvISHKBb3XkVlVdkTBHpmD8C+H3XVeWI4= Received: by 10.91.148.16 with SMTP id a16mr7177824ago.119.1259018405452; Mon, 23 Nov 2009 15:20:05 -0800 (PST) Received: from smtp.gmail.com (173-13-149-190-sfba.hfc.comcastbusiness.net [173.13.149.190]) by mx.google.com with ESMTPS id 5sm2116549yxg.28.2009.11.23.15.20.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Nov 2009 15:20:04 -0800 (PST) Received: by smtp.gmail.com (sSMTP sendmail emulation); Mon, 23 Nov 2009 15:19:00 -0800 Date: Mon, 23 Nov 2009 15:19:00 -0800 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] mtime preservation Message-ID: <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> 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="BOKacYhQ+x31HxR3" Content-Disposition: inline In-Reply-To: <7c612fc60911231049n4a51ddb0u30ae72d8ed93cdec@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Archives-Salt: c15268aa-eee1-4adf-aca4-bc43a3f6329b X-Archives-Hash: 2f8551741ca97f9e53941b9b6fcc9796 --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 23, 2009 at 11:49:25AM -0700, Denis Dupeyron wrote: > 2- Here's the second idea, shamelessly pasted (note that it says EAPI4 > below instead of EAPI3 but this is irrelevant to the idea): >=20 > "Thus, I would let EAPI 4 ebuilds call dopreservemtimes (with an API > similar to docompress) in both src_install and pkg_preinst. Doing so > would instruct the package manager that it must preserve mtimes > (including subsecond, if supported on the filesystem) for a particular > set of paths, even if doing so means no stripping etc. All other mtimes > may be rewritten as the package manager sees fit, and from EAPI 4 > onwards must be rewritten at merge time for anything predating the > start of the build." 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. The thing I'm not understanding here is that pkgcore since day one has=20 preserved mtime- I've yet to see any complaints about that nor any=20 issues caused by it. Portage shifted over a year or two back, same=20 thing, haven't heard complaints. The thing that's bugging me about this whole discussion is that we're=20 spending more time focusing on stupid things the manager could do to=20 (basically intentionally) screw up the mtime preservation. 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". 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. 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. > 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: 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. 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=20 environment. Essentially If we're going to require the manager support NS=20 resolution w/out requiring all FS's involved support NS level=20 resolution, in reality ebuilds can't rely on NS level resolution. =20 Thus drop the requirement since we gain nothing from it- if it's not a=20 gurantee ebuilds can rely on then they should be writing to the lowest=20 common denominator- second level resolution. That may sound heinous,=20 but it's also being realistic. > "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." Yeah... no. Slowing down the main manager for a thereotical edge case=20 doesn't seem particularly useful to me ;) ~harring --BOKacYhQ+x31HxR3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEARECAAYFAksLGGQACgkQsiLx3HvNzgfLLwCgnDwVzjd62Y2fegp83iqs9N14 1TgAoLFqmem2X2ab2SnEqyUVJuHi+66G =hV3m -----END PGP SIGNATURE----- --BOKacYhQ+x31HxR3--