Gentoo Archives: gentoo-council

From: Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>
To: Ulrich Mueller <ulm@g.o>
Cc: gentoo-council@l.g.o
Subject: [gentoo-council] Re: mtime preservation (was: Agenda (draft) for November meeting 2009-11-09)
Date: Wed, 04 Nov 2009 15:28:44
Message-Id: 20091104152835.369e3e18@snowcone
In Reply to: [gentoo-council] mtime preservation (was: Agenda (draft) for November meeting 2009-11-09) by Ulrich Mueller
1 On Wed, 4 Nov 2009 16:07:30 +0100
2 Ulrich Mueller <ulm@g.o> wrote:
3 > Obviously we cannot guarantee anything below the seconds level because
4 > of limitations in the underlying filesystems or software (e.g., tar
5 > for binpkgs). But is there a reason for limiting it further, i.e. not
6 > preserving sub-second timestamps if they are supported by both
7 > filesystems?
8
9 So far as I can see, if they're fully supported on both filesystems,
10 Portage sometimes preserves nanosecond-resolution timestamps and
11 sometimes doesn't. So, requiring nanosecond-resolution timestamp
12 preservation where possible will need Portage changes. But not
13 requiring it means we'll go through this whole thing again as packages
14 start using more accurate timestamps for cache validation things (and
15 yes, this will happen -- we've already hit make-related issues on this
16 front).
17
18 > > * For which files must mtimes be preserved, and which can be
19 > > modified?
20 >
21 > > * Is it the intent of this proposal to prevent package managers from
22 > > automatically rewriting, say, #!/usr/bin/python to
23 > > #!/opt/gentoo/bin/python if prefix is being used?
24 >
25 > Part of the problem (what you call "insufficient clarity") is that the
26 > proposal's original intention was to cover only the merge process,
27 > i.e. what takes place after pkg_preinst. Whereas you want to extend it
28 > to include everything that is taking place after src_install (for
29 > Portage, prepstrip and whatnot).
30 >
31 > If you limit it to the final merge process from D to ROOT, then the
32 > answer is easy, namely mtimes of all regular files must be preserved.
33
34 What I want is for the proposal to be sufficiently specific that it
35 covers exactly what the package manager can and cannot do, and what
36 ebuilds can and cannot rely upon happening. If you require mtime
37 preservation between pkg_preinst and the merge to /, the package
38 manager can just screw things up (by implementing reasonable features)
39 elsewhere. It is by no means clear to me that merely requiring mtime
40 preservation from after pkg_preinst to before pkg_postinst, and
41 allowing arbitrary mtime tinkering elsewhere, is what is desired.
42
43 As an example for the above, is it legal for a package manager to
44 rewrite any mtime that is before the start of the build process if it
45 does it after src_install but before pkg_preinst?
46
47 --
48 Ciaran McCreesh

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
Re: [gentoo-council] Re: mtime preservation Zac Medico <zmedico@g.o>
[gentoo-council] Re: mtime preservation Ulrich Mueller <ulm@g.o>