[gentoo-dev] Re: mtime preservation

2009-11-26 Thread Duncan
David Leverton posted on Thu, 26 Nov 2009 12:35:53 + as excerpted: If we're not going to insist on preserving nanoseconds as far as possible, then package managers should be required to explcitly clear the nanoseconds part. While I'm not sure what it's going to do to install-times and

Re: [gentoo-dev] Re: mtime preservation

2009-11-26 Thread Zac Medico
Duncan wrote: David Leverton posted on Thu, 26 Nov 2009 12:35:53 + as excerpted: If we're not going to insist on preserving nanoseconds as far as possible, then package managers should be required to explcitly clear the nanoseconds part. While I'm not sure what it's going to do to

[gentoo-dev] Re: mtime preservation

2009-11-25 Thread Denis Dupeyron
A quick note to tell you that I have tried to look for examples of breakage due to how mtime preservation is currently implemented in portage. Unfortunately I didn't find anything, maybe because I'm not knowledgeable enough or because I can't afford to spend any more time on this. If any of you

[gentoo-dev] Re: mtime preservation

2009-11-25 Thread Duncan
Ciaran McCreesh posted on Wed, 25 Nov 2009 21:27:18 + as excerpted: Portage uses two ways of merging a file: os.rename() and the manual way. os.rename() correctly preserves mtimes. Python's os.utime call, which is what Portage uses to preserve mtimes for files that it installs the

Re: [gentoo-dev] Re: mtime preservation

2009-11-25 Thread Ciaran McCreesh
On Wed, 25 Nov 2009 21:52:00 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: That's a great explanation (thanks, I now know the details to the degree I'd be interested), but what was asked for was examples of breakage, aka actual bugs. Why? You can easily look and see that it's broken. Examples

[gentoo-dev] Re: mtime preservation

2009-11-25 Thread Duncan
Ciaran McCreesh posted on Wed, 25 Nov 2009 22:13:27 + as excerpted: Examples will merely be dismissed as one-off cases that can be worked around, or as relying upon a string of coincidences that will obviously never really happen, right up until they do, at which point they'll be

[gentoo-dev] Re: mtime preservation

2009-11-25 Thread Duncan
Ulrich Mueller posted on Wed, 25 Nov 2009 23:59:45 +0100 as excerpted: Real examples would be issues like bugs 83877 [1] or 263387 [2]. Nothing that could be easily dismissed or worked around. Both issues are fixed with Portage since a long time. Thanks. I don't know of any example where

[gentoo-dev] Re: mtime preservation

2009-11-25 Thread Duncan
Brian Harring posted on Wed, 25 Nov 2009 17:14:27 -0800 as excerpted: On Wed, Nov 25, 2009 at 04:49:17PM -0800, Zac Medico wrote: Ciaran McCreesh wrote: On Wed, 25 Nov 2009 23:59:45 +0100 Ulrich Mueller u...@gentoo.org wrote: Real examples would be issues like bugs 83877 [1] or 263387

[gentoo-dev] Re: mtime preservation

2009-11-25 Thread Duncan
Zac Medico posted on Wed, 25 Nov 2009 21:26:59 -0800 as excerpted: Brian Harring wrote: This discussion in generall is daft. No package can rely on nanonsecond resolution for installation because the most common FS out there (ext3) does *second* level resolution only. As such, I can pretty

[gentoo-dev] Re: mtime preservation

2009-11-24 Thread Duncan
Brian Harring posted on Mon, 23 Nov 2009 15:19:00 -0800 as excerpted: Alternatively, we could simply make portage spawn the mv binary whenever rename fails (it fails when the source and destination are on different devices). Although it's relatively slow, it should solve the problem.