Gentoo Archives: gentoo-council

From: Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>
To: gentoo-council@l.g.o
Subject: Re: [gentoo-council] Re: mtime preservation
Date: Mon, 09 Nov 2009 16:54:04
Message-Id: 20091109165356.6e38174d@snowcone
In Reply to: Re: [gentoo-council] Re: mtime preservation by Ulrich Mueller
On Mon, 9 Nov 2009 17:37:26 +0100
Ulrich Mueller <ulm@g.o> wrote:
> > What Portage currently does is, more or less, to preserve mtimes > > [...] from every part of the build and merge processes, except for > > an arbitrary set of files that it modifies outside of the ebuild's > > control. > > And exactly this should be the guideline: A modified file may have its > mtime updated, an unmodified file has its mtime preserved. But for > some reason this is not wanted and was countered with arguments such > as "the PM could do two passes of rot-13 encryption".
It's not wanted because it's utterly useless as a specification. It means ebuilds can't rely upon any file having its mtime preserved, because a package manager can decide, reasonably or otherwise, to modify any file it likes. The double-rot-13 argument is merely a compact illustration of why leaving it open is unworkable. If you prefer a more subtle argument, consider "the package manager might want to rewrite #!/usr/bin/python lines automatically in Prefix environments", but be aware that any example of that nature is prone to being sidetracked into arguments about "but Prefix won't do it that way", entirely missing the wider point. Now, you could claim, as you do, that the proposal should only matter for pkg_preinst to merge mtime preservation, and so rewriting of this kind is fine if it's done straight after src_install. But we have yet to establish whether every ebuild mtime-related operation is best done exclusively in pkg_preinst (and this is far from a straight-forward question, when you have to start thinking about binaries and about cleanup), and it's not safe to jump to the conclusion that allowing the package manager to modify things straight after src_install is safe and in line with what best suits developers.
> > None of these strike me as reasonable solutions, and I am still of > > the opinion that this isn't something that should have been rushed > > into EAPI 3 > > The respective bug was opened in March, more than 7 months ago. That's > not what I would call "rush".
And it was left out of EAPI 3 originally because no appropriate solution had been found. As you're aware, there's a finite amount of time that can be spent working on these things, and thus-far not enough of that time has been devoted to turning this into a solvable problem.
> > without people having spent time taking a good look at what all > > mtime preservation would be needed to do, what Portage currently > > does (since it does not, as some people have claimed, preserve > > mtimes) and what should be done about packages that end up > > installing files with absurd mtimes. > > > If guaranteed mtime preservation is a desired feature, we should be > > designing it around what developers need, not around what Portage > > currently does. > > What if the two coincide?
They don't. I have yet to see any argument in favour of random and inconsistent clobbering of sub-second mtimes, and I have yet to see any argument in favour of files with a timestamp of 1 Jan 1970 being merged to /, other than that Portage currently does both of those things. -- Ciaran McCreesh

Attachments

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