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 1NDg5Q-0000lH-AL for garchives@archives.gentoo.org; Thu, 26 Nov 2009 15:16:48 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 74D79E088A; Thu, 26 Nov 2009 15:15:40 +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 125B6E088A for ; Thu, 26 Nov 2009 15:15:39 +0000 (UTC) Received: by bwz7 with SMTP id 7so652035bwz.26 for ; Thu, 26 Nov 2009 07:15:39 -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=YsxnjXQF058LqN3zmFNzzmKuJHQ1YxoHAWIguJyKpIc=; b=fSouHC+XCIq5luntgVE7kG/q0CncMqx+npzpXNi1otJW6dza6LpCNGRDlhuFGjq88B E4wEFXlqUCRhgxoDdX36V16sox6gIYaUQ+Df/ANRht10YcxbH3MSuW9tJaskjwXf8CX4 rggXVIicXd6WCRBOpUoXZ3+Yup4yceZDAfA+Q= 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=UB17mRq9jLGim4h5HTruB6tIH9WPafHPsdF2VgD3vQVWu0Cl4a4wJ74ii0tzqRPHKU +PWEyKzoJLAQyb8T2lqOHxJFWDRmEGZ9MspiR/+a9VD1W0z8hpq4lfyS9lhlzxZyF9w3 28st+x/NAK5P92Y/6T0tuwsPB+oqK17k9Lv5g= Received: by 10.204.21.4 with SMTP id h4mr843469bkb.58.1259248539272; Thu, 26 Nov 2009 07:15:39 -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 16sm266070fxm.4.2009.11.26.07.15.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Nov 2009 07:15:39 -0800 (PST) Date: Thu, 26 Nov 2009 15:15:27 +0000 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] mtime preservation Message-ID: <20091126151527.1dbe288d@snowcone> In-Reply-To: <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> <20091126012833.GE23443@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_/bdtTcP+bhFc2wzYIv+jyHpR"; protocol="application/pgp-signature" X-Archives-Salt: d3d5faed-969c-48c1-89fc-34be8979a45e X-Archives-Hash: bc73818679db50d715d0bf4c326dbf89 --Sig_/bdtTcP+bhFc2wzYIv+jyHpR Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 25 Nov 2009 17:28:33 -0800 Brian Harring wrote: > > It's not in the least bit nasty. It's requiring people to be > > explicit about special requirements. >=20 > I honestly wish that explicitness you're pushing for mtime were=20 > applied to all parts of mtime. >=20 > 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). No, two out of three do a half-arsed job about it. If we're going to make it behaviour upon which packages can rely, we should be doing so properly to avoid the whole mess cropping up again as people start following the newer POSIX standard. > > You can't have been listening very hard, then. The complaint is > > that it results in files with dumb mtimes being merged to /. >=20 > As far as I can tell, no one but you is complaining about the > mtimes. =20 >=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. Yes, again, it's about doing it properly. > > 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. >=20 > That wording is explicit that PMS cannot lock down all potentials. =20 Ok, so PMS would effectively say "ebuilds must not rely upon any particular behaviour", which in turn means any ebuild that breaks with older Portage / Paludis is broken. That's not what you're after, is it? > 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. That one's being fixed, slowly... > 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. These are entirely unrelated. Any ebuild that relies upon the slash either way is broken. But we can't realistically do that for mtimes, since it would involve modifying *the package that gets installed*, and doing so by patching sources to use things POSIX considers deprecated. It's not just an ebuild tweak. > The daft thing about you picking at this wording is that the > scenarios you can come up with are all hypothetical. Yes, a manager > could randomize mtimes when it's doing splitdebug. >=20 > The manager wouldn't however because the only reason to do things > like that is to intentionally cause issues. It's about doing it right, so we don't get bitten by it later on when everyone's using nanosecond-resolution timestamps like POSIX suggests. --=20 Ciaran McCreesh --Sig_/bdtTcP+bhFc2wzYIv+jyHpR Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAksOm5IACgkQ96zL6DUtXhH6PQCgzodz13yHL7C+/Nw6AZ3RqBlo u2QAnAzfxvoYd15GsDHUxOPa/5Njmj/O =4PZ5 -----END PGP SIGNATURE----- --Sig_/bdtTcP+bhFc2wzYIv+jyHpR--