Re: [gentoo-dev] mtime preservation

[Ciaran McCreesh <ciaran.mccreesh@googlemail.com>]

[-- Attachment #1: Type: text/plain, Size: 3378 bytes --]

On Wed, 25 Nov 2009 17:28:33 -0800
Brian Harring <ferringb@gmail.com> wrote:
> > It's not in the least bit nasty. It's requiring people to be
> > explicit about special requirements.
> 
> I honestly wish that explicitness you're pushing for mtime were 
> applied to all parts of mtime.
> 
> Why is this one special?  Two out of three do this already, and it 
> works.  Paludis doesn't preserve mtime- and it's approach to randomly 
> resetting mtimes is known to cause issues (bug 263387, python eclass 
> having to do pyc/pyo compilation in postinst, etc).

No, two out of three do a half-arsed job about it. If we're going to
make it behaviour upon which packages can rely, we should be doing so
properly to avoid the whole mess cropping up again as people start
following the newer POSIX standard.

> > You can't have been listening very hard, then. The complaint is
> > that it results in files with dumb mtimes being merged to /.
> 
> As far as I can tell, no one but you is complaining about the
> mtimes.  
> 
> Your complaints primarily have been that tarball'd mtimes can pass 
> through to the fs- I've not seen any comments from you in bug 264130 
> that actually enumerate spots were this is anything but an aesthetic 
> complaint.  Specifically your aesthetics- the pkgs in question have 
> functioned fine w/ odd mtimes passing through.

Yes, again, it's about doing it properly.

> > Wording such as that just isn't suitable for a specification. It
> > requires implementers to guess what future ebuilds are going to
> > rely upon (and ebuilds regularly do rely upon weird quirks), and
> > makes it impossible to produce a package manager that can be shown
> > to be compliant.
> 
> That wording is explicit that PMS cannot lock down all potentials.  

Ok, so PMS would effectively say "ebuilds must not rely upon any
particular behaviour", which in turn means any ebuild that breaks with
older Portage / Paludis is broken. That's not what you're after, is it?

> This is no different then PMS's stance on VDB (and similar in 
> reasoning)- ebuilds are reliant on vdb internals yet PMS explicitly 
> ducked documenting it.  Double standards suck.

That one's being fixed, slowly...

> Further, drop the specificity BS.  You've intentionally left parts of 
> PMS vague- trailing '/' for ebuild vars is a good example (ssmtp 
> breaks if ${D} vs ${D}/, perl likely has the same breakage).  These 
> lead to actual incompatibilities, and because PMS isn't explicit, 
> there is no 'right' implementation for it.

These are entirely unrelated. Any ebuild that relies upon the slash
either way is broken. But we can't realistically do that for mtimes,
since it would involve modifying *the package that gets installed*, and
doing so by patching sources to use things POSIX considers deprecated.
It's not just an ebuild tweak.

> The daft thing about you picking at this wording is that the
> scenarios you can come up with are all hypothetical.  Yes, a manager
> could randomize mtimes when it's doing splitdebug.
> 
> The manager wouldn't however because the only reason to do things
> like that is to intentionally cause issues.

It's about doing it right, so we don't get bitten by it later on when
everyone's using nanosecond-resolution timestamps like POSIX suggests.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]