Gentoo Logo
Gentoo Spaceship

Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-council
Lists: gentoo-council: < Prev By Thread Next > < Prev By Date Next >
To: Ulrich Mueller <ulm@g.o>
From: Ciaran McCreesh <ciaran.mccreesh@...>
Subject: Re: mtime preservation (was: Agenda (draft) for November meeting 2009-11-09)
Date: Wed, 4 Nov 2009 15:28:35 +0000
On Wed, 4 Nov 2009 16:07:30 +0100
Ulrich Mueller <ulm@g.o> wrote:
> Obviously we cannot guarantee anything below the seconds level because
> of limitations in the underlying filesystems or software (e.g., tar
> for binpkgs). But is there a reason for limiting it further, i.e. not
> preserving sub-second timestamps if they are supported by both
> filesystems?

So far as I can see, if they're fully supported on both filesystems,
Portage sometimes preserves nanosecond-resolution timestamps and
sometimes doesn't. So, requiring nanosecond-resolution timestamp
preservation where possible will need Portage changes. But not
requiring it means we'll go through this whole thing again as packages
start using more accurate timestamps for cache validation things (and
yes, this will happen -- we've already hit make-related issues on this

> > * For which files must mtimes be preserved, and which can be
> > modified?
> > * Is it the intent of this proposal to prevent package managers from
> >   automatically rewriting, say, #!/usr/bin/python to
> >   #!/opt/gentoo/bin/python if prefix is being used?
> Part of the problem (what you call "insufficient clarity") is that the
> proposal's original intention was to cover only the merge process,
> i.e. what takes place after pkg_preinst. Whereas you want to extend it
> to include everything that is taking place after src_install (for
> Portage, prepstrip and whatnot).
> If you limit it to the final merge process from D to ROOT, then the
> answer is easy, namely mtimes of all regular files must be preserved.

What I want is for the proposal to be sufficiently specific that it
covers exactly what the package manager can and cannot do, and what
ebuilds can and cannot rely upon happening. If you require mtime
preservation between pkg_preinst and the merge to /, the package
manager can just screw things up (by implementing reasonable features)
elsewhere. It is by no means clear to me that merely requiring mtime
preservation from after pkg_preinst to before pkg_postinst, and
allowing arbitrary mtime tinkering elsewhere, is what is desired.

As an example for the above, is it legal for a package manager to
rewrite any mtime that is before the start of the build process if it
does it after src_install but before pkg_preinst?

Ciaran McCreesh
signature.asc (PGP signature)
Re: mtime preservation
-- Ulrich Mueller
Re: Re: mtime preservation
-- Zac Medico
Agenda (draft) for November meeting 2009-11-09
-- Ulrich Mueller
Re: Agenda (draft) for November meeting 2009-11-09
-- Ciaran McCreesh
mtime preservation (was: Agenda (draft) for November meeting 2009-11-09)
-- Ulrich Mueller
Lists: gentoo-council: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
mtime preservation (was: Agenda (draft) for November meeting 2009-11-09)
Next by thread:
Re: Re: mtime preservation
Previous by date:
Re: Agenda (draft) for November meeting 2009-11-09
Next by date:
Re: Re: mtime preservation

Updated Nov 13, 2011

Summary: Archive of the gentoo-council mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.