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 1NDTAO-00060v-Jr for garchives@archives.gentoo.org; Thu, 26 Nov 2009 01:29:04 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5481EE0A6C; Thu, 26 Nov 2009 01:28:37 +0000 (UTC) Received: from mail-yx0-f189.google.com (mail-yx0-f189.google.com [209.85.210.189]) by pigeon.gentoo.org (Postfix) with ESMTP id 3080DE0A6C for ; Thu, 26 Nov 2009 01:28:37 +0000 (UTC) Received: by yxe27 with SMTP id 27so272710yxe.10 for ; Wed, 25 Nov 2009 17:28:36 -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=qJWFYpuT3cucObCxpXG89TBc5D3r9Hqie8w67X4X240=; b=cv9eJh0EcDzkxWoadh+D/78i065RvjWt4mjCEw9CV9zKeP+S2FFXbxnAUhNaHOkci3 xST2vhIg4yi6c1y/xMQzVPUH49VcIVmD2FTs6/5GpuTTdMURipwps6y31xDHqbm4/u0T obPm9oReD/7ticGOtluB9OHjBaJtFcYe8MDPQ= 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=L+5oVNe0C4I4iCLcKXNX8fC3a+BYPKQQSlKL18RYdXlHgYCoFpjPzJbO4XcGP9ftT4 mz8u8b5Mt/duQpoOUgB/d+aNm3tWap0UzLHmVADkDyyECvPtiTlrdRQNqPUx2BkAHZgo jh+Eo2zG5TNfjUIqPu0vy+DgvuLwfHZ8Sd6Tk= Received: by 10.90.127.20 with SMTP id z20mr11122659agc.118.1259198916714; Wed, 25 Nov 2009 17:28:36 -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 8sm108986yxb.25.2009.11.25.17.28.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Nov 2009 17:28:35 -0800 (PST) Received: by smtp.gmail.com (sSMTP sendmail emulation); Wed, 25 Nov 2009 17:28:33 -0800 Date: Wed, 25 Nov 2009 17:28:33 -0800 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] mtime preservation Message-ID: <20091126012833.GE23443@hrair> References: <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> <20091124222106.7984b750@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="GID0FwUMdk1T2AWN" Content-Disposition: inline In-Reply-To: <20091124222106.7984b750@snowcone> User-Agent: Mutt/1.5.20 (2009-06-14) X-Archives-Salt: b53b2e28-0e3d-4e77-8b66-60b888306567 X-Archives-Hash: bc42c179688e398eafa543b69773e2d5 --GID0FwUMdk1T2AWN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 24, 2009 at 10:21:06PM +0000, Ciaran McCreesh wrote: > 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. >=20 > It's not in the least bit nasty. It's requiring people to be explicit > about special requirements. I honestly wish that explicitness you're pushing for mtime were=20 applied to all parts of mtime. Why is this one special? Two out of three do this already, and it=20 works. Paludis doesn't preserve mtime- and it's approach to randomly=20 resetting mtimes is known to cause issues (bug 263387, python eclass=20 having to do pyc/pyo compilation in postinst, etc). > > 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. >=20 > You can't have been listening very hard, then. The complaint is that it > results in files with dumb mtimes being merged to /. As far as I can tell, no one but you is complaining about the mtimes. =20 Your complaints primarily have been that tarball'd mtimes can pass=20 through to the fs- I've not seen any comments from you in bug 264130=20 that actually enumerate spots were this is anything but an aesthetic=20 complaint. Specifically your aesthetics- the pkgs in question have=20 functioned fine w/ odd mtimes passing through. > > 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. >=20 > 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. That wording is explicit that PMS cannot lock down all potentials. =20 This is no different then PMS's stance on VDB (and similar in=20 reasoning)- ebuilds are reliant on vdb internals yet PMS explicitly=20 ducked documenting it. Double standards suck. Further, drop the specificity BS. You've intentionally left parts of=20 PMS vague- trailing '/' for ebuild vars is a good example (ssmtp=20 breaks if ${D} vs ${D}/, perl likely has the same breakage). These=20 lead to actual incompatibilities, and because PMS isn't explicit,=20 there is no 'right' implementation for it. The daft thing about you picking at this wording is that the scenarios=20 you can come up with are all hypothetical. Yes, a manager could=20 randomize mtimes when it's doing splitdebug. The manager wouldn't however because the only reason to do things like=20 that is to intentionally cause issues. ~brian --GID0FwUMdk1T2AWN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEARECAAYFAksN2cEACgkQsiLx3HvNzgc6+wCguGrj4WZzinUcDq9tm+t08t1E SMoAoNe+oNeaCYRQonagtpBe+m6Fj9XU =bT+1 -----END PGP SIGNATURE----- --GID0FwUMdk1T2AWN--