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 1NCfSw-00084F-3i for garchives@archives.gentoo.org; Mon, 23 Nov 2009 20:24:54 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AF62FE0BE3 for ; Mon, 23 Nov 2009 20:24:53 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 268DFE080B; Mon, 23 Nov 2009 18:49:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id BF19AB49F7; Mon, 23 Nov 2009 18:49:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 required=5.5 tests=[AWL=0.633, BAYES_00=-2.599] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMAHkQurACYi; Mon, 23 Nov 2009 18:49:27 +0000 (UTC) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by smtp.gentoo.org (Postfix) with ESMTP id A16A7B49EF; Mon, 23 Nov 2009 18:49:26 +0000 (UTC) Received: by fxm28 with SMTP id 28so1681518fxm.25 for ; Mon, 23 Nov 2009 10:49:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=e+ig43+m1EsaQ/0uhLWo43NXLWJVtBEIUHPqxFY3kao=; b=XGjiq6mctLFhp7dW2WnwmqPQwKuIzXpU7TS0HdMUErfPKO9qTd2LEiD4xTE5nFaE9/ FAtAJox4AYH63ZgG6uaocuA7b0DQTbPua4n2Mu4jYwkMq9UdZI+RinHS/G2Qy3eZV37t JIyu6in1XijCUoYbH+sRZNXzV+7v7xdxygeOU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=M+2xmCharrLueDwDEdfQrSPAwXlg+EPS2Hz8EufdJXezdUNe9ovHBk0qr1WdpvHrWy xlyDT8RzfKE6VyJ9D6vGC49P/CeczKuff9P5KFb79DVjb1gTcBP209deZUhTiz0o4mUj 26UzUA1waoecsisMnS6b5dL/praH8WZHorMU4= 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 Sender: denis.dupeyron@gmail.com Received: by 10.216.89.10 with SMTP id b10mr1680617wef.182.1259002165311; Mon, 23 Nov 2009 10:49:25 -0800 (PST) In-Reply-To: <4B07362D.2010108@gentoo.org> References: <19184.25176.380022.392451@a1i15.kph.uni-mainz.de> <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> Date: Mon, 23 Nov 2009 11:49:25 -0700 X-Google-Sender-Auth: 1ce1703e2ebe551c Message-ID: <7c612fc60911231049n4a51ddb0u30ae72d8ed93cdec@mail.gmail.com> Subject: [gentoo-dev] mtime preservation From: Denis Dupeyron To: gentoo-dev@lists.gentoo.org Cc: gentoo-dev-announce@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 X-Archives-Salt: 72526187-37d8-4cad-a2c0-f366ce62e2ae X-Archives-Hash: a9e26414f2278275bdfa08baf839704f I'm going to try and sum up the situation of the thread started in [1]. Feel free to correct me or add to the summary in replies. There seems to be two main ideas. I have removed the authors' name in quotes below in order to make sure we talk about the ideas and not who proposed them. 1- All packages are treated equally. Some files have their mtime preserved, some don't. We need to agree on what files have their mtime preserved and at what phase the mtime is frozen. What we seemed to have agreed on is that the wording in PMS needs to be unambiguous enough that it doesn't defeat the purpose. Here's a first proposition: "The package manager must preserve modification times of regular files. This includes files being compressed before merging. Exceptions to this are: (Now we need to enumerate the exceptions:) * files newly created by the package manager, (This will cover splitdebug, for example. (And please don't tell me that the wording is flawed because the PM could save a file's contents in some buffer, then delete the file and create it newly. This would be as unreasonable as the rot-13 example.) ) * binary object files being stripped of symbols. (Anything else missing from above list?)" 2- Here's the second idea, shamelessly pasted (note that it says EAPI4 below instead of EAPI3 but this is irrelevant to the idea): "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." 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: "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." My intention is to ask the council to vote on which method is preferable in two weeks. I will also ask the council on whether we still want mtime preservation for EAPI3 or if we now think it's better to push it to EAPI4. Please discuss. Denis. [1] http://archives.gentoo.org/gentoo-council/msg_becc15a2882cc7e4f1079b2f9f4dcaad.xml