| 1 |
2009/11/26 Brian Harring <ferringb@×××××.com>: |
| 2 |
> This discussion in generall is daft. No package can rely on |
| 3 |
> nanonsecond resolution for installation because the most common FS out |
| 4 |
> there (ext3) does *second* level resolution only. As such, I can |
| 5 |
> pretty much gurantee there is *zero* packages out there that require |
| 6 |
> nanosecond resolution for installation. |
| 7 |
|
| 8 |
It's possible that a package might assume that *if* nanosecond |
| 9 |
timestamps were available on the build filesystem, then they can do |
| 10 |
nanosecond comparisons on the installed filesystem. That would be a |
| 11 |
rather questionable assumption, and I'm not sure what we could do |
| 12 |
about packages that do require that, but that's why we discuss things, |
| 13 |
right? To find solutions? |
| 14 |
|
| 15 |
> It's an academic discussion, and pointless. We don't mandate the |
| 16 |
> filesystems PMS implementations are run on- as such we cannot make a |
| 17 |
> gurantee to ebuilds that nanosecond resolution is available. It's |
| 18 |
> daft to encode in the spec NS resolution when it's essentially |
| 19 |
> impossible to gurantee it |
| 20 |
|
| 21 |
If we're not going to insist on preserving nanoseconds as far as |
| 22 |
possible, then package managers should be required to explcitly clear |
| 23 |
the nanoseconds part. Otherwise we'll get situations where a package |
| 24 |
works on the maintainer's machine, because it happens to use a package |
| 25 |
manager, filesystem setup, configuration etc that happens to cause |
| 26 |
nanoseconds to be preserved accurately, but it randomly and |
| 27 |
mysteriously fails for users. This is especially a concern in this |
| 28 |
case because a maintainer can easily have no idea that he's |
| 29 |
accidentally relying on nanoseconds being preserved - it's not |
| 30 |
something the ebuild requests explicitly, and if the timestamps happen |
| 31 |
to be set on his machine as the package expects, it'll just work |
| 32 |
without any indication that there was a potential issue. |
| 33 |
|
| 34 |
> I'm honestly not sure why we're having this discussion beyond the "python sucks" angle. |
| 35 |
|
| 36 |
Because some of us want to find a correct solution, not just one that |
| 37 |
no-one's complained about yet in the context of the few filetypes that |
| 38 |
are currently known to benefit from preservation. Shocking, I know. |
Archives