On Tue, Nov 24, 2009 at 10:21:06PM +0000, Ciaran McCreesh wrote:
> On Mon, 23 Nov 2009 15:19:00 -0800
> Brian Harring <ferringb@gmail.com> wrote:
> > Someone mind explaining to me why we're making mtime preservation so 
> > nasty?  Having to enumerate every pathway that requires mtime 
> > preservation is pretty arduous for the ebuild dev, meaning it's 
> > unlikely they'll get it right, leading to bugs.
> 
> 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).


> > The thing I'm not understanding here is that pkgcore since day one
> > has preserved mtime- I've yet to see any complaints about that nor
> > any issues caused by it.  Portage shifted over a year or two back,
> > same thing, haven't heard complaints.
> 
> 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.


> > I know it won't fly, but realistically stating "the package manager 
> > must preserve mtime- if there are instances where it does not (due to 
> > some feature, perhaps splitdebug or some form of compression) it is 
> > the package managers responsibility to ensure this does not break the 
> > ebuilds resultant merge/runtime invocation".
> > 
> > Via such wording an exemption is created and it's made clear it's the 
> > managers responsibility to keep things playing nice... if the manager 
> > can't do that, then the feature/functionality that is changing the 
> > mtime (resulting in the pkg on disk failing) must be fixed or 
> > disabled.
> > 
> > The nice thing about this wording is that it basically matches what 
> > the case is now, and what has worked for quite a few years.
> 
> 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.  
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.

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.

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.

~brian