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 [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 that is > > undefined behaviour, and that behaves differently depending upon the > > Portage version you use. > > > >> I don't know of any example where non-preservation of nanosecond > >> timestamps would cause problems. > > > > 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 timestamp comparisons?
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 nanosecond resolution for installation. 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. It's daft to encode in the spec NS resolution when it's essentially impossible to gurantee it- I'm honestly not sure why we're having this discussion beyond the "python sucks" angle. ~brian
pgp89cUgiTHJ1.pgp
Description: PGP signature
