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 1NDdaJ-0001Go-1v for garchives@archives.gentoo.org; Thu, 26 Nov 2009 12:36:31 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 109D4E0879; Thu, 26 Nov 2009 12:35:54 +0000 (UTC) Received: from mail-yw0-f174.google.com (mail-yw0-f174.google.com [209.85.211.174]) by pigeon.gentoo.org (Postfix) with ESMTP id B3BE3E0879 for ; Thu, 26 Nov 2009 12:35:54 +0000 (UTC) Received: by ywh4 with SMTP id 4so582276ywh.10 for ; Thu, 26 Nov 2009 04:35:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=xS7OIQNXt6X2LVH6f3YPy2MGhwON31Q4HXLLwJZyvD8=; b=AzKr5EUXiOSdCOf1t1sAYKjLe7ue959Ltj8P9AiiBXPD8bWKqhAGr8mv9EiMqHuEcH 3ZtAr3NbnzRPyvJZOAWFnDuGLgcwNeqmsn+f+vJl3zyuc/4z0Axc/4ykqpNgwJ/m+Ijb DWKC2tKA6oxoq7vimJD6XIwjcQlTJhfGSXhlk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=bI/vLRWMOs7JE1TKwMNLxC0hsPv6R5wuaW7TdOywwomOJGyn+RhiXi3JfXyvXq/4wM yhH6EJnadHE2Cw17YX30v0GSF0LAb8HhQg/i6zwJ8ovsapt3nQ0DBcjwx3Nj9Car3b2F qHl7DKtPkNm/EFhYL8+kLleJ700juMoDyC9Ls= 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 Received: by 10.101.29.11 with SMTP id g11mr6177691anj.125.1259238953905; Thu, 26 Nov 2009 04:35:53 -0800 (PST) In-Reply-To: <20091126011427.GD23443@hrair> References: <20091120001820.7274bdf7@snowmobile> <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> <20091126011427.GD23443@hrair> Date: Thu, 26 Nov 2009 12:35:53 +0000 Message-ID: <75f3dce80911260435k7b3228b1pb71ebd602f00320b@mail.gmail.com> Subject: Re: [gentoo-dev] mtime preservation From: David Leverton To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: cd5a38aa-c3c2-4aba-a6eb-b0c4b3b75298 X-Archives-Hash: 11f52a6e17cd02b871b755cf0f3e5e4f 2009/11/26 Brian Harring : > This discussion in generall is daft. =C2=A0No package can rely on > nanonsecond resolution for installation because the most common FS out > there (ext3) does *second* level resolution only. =C2=A0As such, I can > pretty much gurantee there is *zero* packages out there that require > nanosecond resolution for installation. It's possible that a package might assume that *if* nanosecond timestamps were available on the build filesystem, then they can do nanosecond comparisons on the installed filesystem. That would be a rather questionable assumption, and I'm not sure what we could do about packages that do require that, but that's why we discuss things, right? To find solutions? > It's an academic discussion, and pointless. =C2=A0We don't mandate the > filesystems PMS implementations are run on- as such we cannot make a > gurantee to ebuilds that nanosecond resolution is available. =C2=A0It's > daft to encode in the spec NS resolution when it's essentially > impossible to gurantee it If we're not going to insist on preserving nanoseconds as far as possible, then package managers should be required to explcitly clear the nanoseconds part. Otherwise we'll get situations where a package works on the maintainer's machine, because it happens to use a package manager, filesystem setup, configuration etc that happens to cause nanoseconds to be preserved accurately, but it randomly and mysteriously fails for users. This is especially a concern in this case because a maintainer can easily have no idea that he's accidentally relying on nanoseconds being preserved - it's not something the ebuild requests explicitly, and if the timestamps happen to be set on his machine as the package expects, it'll just work without any indication that there was a potential issue. > I'm honestly not sure why we're having this discussion beyond the "python= sucks" angle. Because some of us want to find a correct solution, not just one that no-one's complained about yet in the context of the few filetypes that are currently known to benefit from preservation. Shocking, I know.