On Thursday 26 November 2009 13:21:43 Brian Harring wrote:
> It was always on the todo to convert portage over to preserving mtime-
> this long predates PMS and even EAPI.
Like, for example, use deps? Yet somehow we managed to introduce those in a
new EAPI, instead of retroactively adding them t
On Thu, 26 Nov 2009 08:59:44 +0100
Ulrich Mueller wrote:
> >> Not non-preservation. Partial and inconsistent corruption.
>
> > Wouldn't "loss of precision" be a more accurate description?
>
> Yes. Or even "rounding".
No, corruption, including of the seconds part, is the right way to
describe it
On Wed, 25 Nov 2009 17:14:27 -0800
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 much gurantee there is *zer
On Wed, 25 Nov 2009 16:49:17 -0800
Zac Medico wrote:
> > Not non-preservation. Partial and inconsistent corruption.
>
> Wouldn't "loss of precision" be a more accurate description? Of the
> known packages which require timestamp preservation, do any of them
> use sub-second precision in their tim
On Wed, 25 Nov 2009 17:28:33 -0800
Brian Harring 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? Tw
On Thu, Nov 26, 2009 at 12:35:53PM +, David Leverton wrote:
> 2009/11/26 Brian Harring :
> > It's an academic discussion, and pointless. We don't mandate the
> > filesystems PMS implementations are run on- as such we cannot make a
> > gurantee to ebuilds that nanosecond resolution is available
Potentially just being a tool and taking the bait..
On Thu, Nov 26, 2009 at 12:41:55PM +, David Leverton wrote:
> 2009/11/26 Brian Harring :
> > Why is this one special? Two out of three do this already, and it
> > works.
>
> You mean "two out of three blatently ignored long-standing behavio
2009/11/26 Brian Harring :
> Why is this one special? Two out of three do this already, and it
> works.
You mean "two out of three blatently ignored long-standing behaviour
and added a new feature without discussion or an EAPI bump".
> Paludis doesn't preserve mtime
You mean "Paludis carefully
2009/11/26 Brian Harring :
> 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 much gurantee there is *zero* packages out there that requi
> On Thu, 26 Nov 2009, Łukasz Michalik wrote:
>> I can speak for Emacs only, where the comparison code (in fileio.c) is
>> as follows:
>>
> [snip]
>>
>> It uses stat(2), therefore nanoseconds are ignored.
> So, when that is updated to require nanosecond resolution where
> supported, we're o
On 08:59 2009-11-26 +0100, Ulrich Mueller wrote:
>
> I can speak for Emacs only, where the comparison code (in fileio.c) is
> as follows:
>
[snip]
>
> It uses stat(2), therefore nanoseconds are ignored.
>
So, when that is updated to require nanosecond resolution where
supported, we're off to h
> On Thu, 26 Nov 2009, Ulrich Mueller wrote:
> On Wed, 25 Nov 2009, Zac Medico wrote:
>> Of the known packages which require timestamp preservation, do any
>> of them use sub-second precision in their timestamp comparisons?
> I can speak for Emacs only, where the comparison code (in filei
> On Wed, 25 Nov 2009, Zac Medico wrote:
>> Not non-preservation. Partial and inconsistent corruption.
> Wouldn't "loss of precision" be a more accurate description?
Yes. Or even "rounding".
> Of the known packages which require timestamp preservation, do any
> of them use sub-second precis
> On Thu, 26 Nov 2009, Ciaran McCreesh wrote:
>> 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.
> Yes, those are examples of packages relying upon something t
On Wed, Nov 25, 2009 at 09:26:59PM -0800, Zac Medico wrote:
> 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
> >
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 much gurantee there is *zero* packages out there that require
On Tue, Nov 24, 2009 at 10:21:06PM +, Ciaran McCreesh wrote:
> On Mon, 23 Nov 2009 15:19:00 -0800
> Brian Harring 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 arduo
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 wrote:
> >> Real examples would be issues like bugs 83877 [1] or 263387 [2].
> >> Nothing that could be easily dismissed or worked around. Both issues
> >>
Ciaran McCreesh wrote:
> On Wed, 25 Nov 2009 23:59:45 +0100
> Ulrich Mueller wrote:
>> 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.
>
> Yes, those are examples
On Wed, 25 Nov 2009 23:59:45 +0100
Ulrich Mueller wrote:
> 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.
Yes, those are examples of packages relying upon something
> On Wed, 25 Nov 2009, Ciaran McCreesh wrote:
> 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
On Mon, 23 Nov 2009 15:19:00 -0800
Brian Harring 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, leadi
On Mon, Nov 23, 2009 at 11:49:25AM -0700, Denis Dupeyron wrote:
> 2- Here's the second idea, shamelessly pasted (note that it says EAPI4
> below instead of EAPI3 but this is irrelevant to the idea):
>
> "Thus, I would let EAPI 4 ebuilds call dopreservemtimes (with an API
> similar to docompress) i
Denis Dupeyron wrote:
> 1- All packages are treated equally. Some files have their mtime
> preserved, some don't. We need to agree on what files have their mtime
> preserved and at what phase the mtime is frozen.
I'd vote for method 1.
> My intention is to ask the council to vote on which method
I'm going to try and sum up the situation of the thread started in
[1]. Feel free to correct me or add to the summary in replies.
There seems to be two main ideas. I have removed the authors' name in
quotes below in order to make sure we talk about the ideas and not who
proposed them.
1- All pack
25 matches
Mail list logo
