1 |
On Mon, 23 Nov 2009 15:19:00 -0800 |
2 |
Brian Harring <ferringb@×××××.com> wrote: |
3 |
> Someone mind explaining to me why we're making mtime preservation so |
4 |
> nasty? Having to enumerate every pathway that requires mtime |
5 |
> preservation is pretty arduous for the ebuild dev, meaning it's |
6 |
> unlikely they'll get it right, leading to bugs. |
7 |
|
8 |
It's not in the least bit nasty. It's requiring people to be explicit |
9 |
about special requirements. |
10 |
|
11 |
> The thing I'm not understanding here is that pkgcore since day one |
12 |
> has preserved mtime- I've yet to see any complaints about that nor |
13 |
> any issues caused by it. Portage shifted over a year or two back, |
14 |
> same thing, haven't heard complaints. |
15 |
|
16 |
You can't have been listening very hard, then. The complaint is that it |
17 |
results in files with dumb mtimes being merged to /. |
18 |
|
19 |
> I know it won't fly, but realistically stating "the package manager |
20 |
> must preserve mtime- if there are instances where it does not (due to |
21 |
> some feature, perhaps splitdebug or some form of compression) it is |
22 |
> the package managers responsibility to ensure this does not break the |
23 |
> ebuilds resultant merge/runtime invocation". |
24 |
> |
25 |
> Via such wording an exemption is created and it's made clear it's the |
26 |
> managers responsibility to keep things playing nice... if the manager |
27 |
> can't do that, then the feature/functionality that is changing the |
28 |
> mtime (resulting in the pkg on disk failing) must be fixed or |
29 |
> disabled. |
30 |
> |
31 |
> The nice thing about this wording is that it basically matches what |
32 |
> the case is now, and what has worked for quite a few years. |
33 |
|
34 |
Wording such as that just isn't suitable for a specification. It |
35 |
requires implementers to guess what future ebuilds are going to |
36 |
rely upon (and ebuilds regularly do rely upon weird quirks), and makes |
37 |
it impossible to produce a package manager that can be shown to be |
38 |
compliant. |
39 |
|
40 |
> > In both cases nanosecond resolution may be required and is a problem |
41 |
> > due to python. The following workaround can be used until the |
42 |
> > nanosecond issue is fixed in python: |
43 |
> |
44 |
> It'd be nice if someone enumerated merge scenarios where nanosecond |
45 |
> resolution is actually required. Seems like a white elephant to me, |
46 |
> especially in combination w/ the fact that the target fs may not |
47 |
> support nanosecond. |
48 |
|
49 |
POSIX considers several of the non-nanosecond resolution calls to be |
50 |
deprecated. Going "la la la I can't hear you!" because Python happens |
51 |
to have utterly screwed this up is just going to lead to problems when |
52 |
programs start using sub-second validity checks -- 'make' already does, |
53 |
and it's given rise to various build-directory-related issues. |
54 |
|
55 |
> Basically, if it's required the manager support nanosecond resolution |
56 |
> for merging, ebuilds must be able to rely on that- end result, any |
57 |
> merging to FS's that do not support nanosecond (this includes the |
58 |
> intermediate ${D}) are no longer supported. Unless I'm missing |
59 |
> something, iso-9660 doesn't look to support nanosecond resolution. |
60 |
> Beyond that, does cramfs/squashfs? If not, taking this to the |
61 |
> logical conclusion the livecds aren't technically supported as a |
62 |
> merge environment. |
63 |
|
64 |
No, we're after a requirement that the package manager must not screw up |
65 |
nanosecond-resolution timestamps, and must not partially preserve and |
66 |
partially not preserve them. |
67 |
|
68 |
> > "Alternatively, we could simply make portage spawn the mv binary |
69 |
> > whenever rename fails (it fails when the source and destination are |
70 |
> > on different devices). Although it's relatively slow, it should |
71 |
> > solve the problem." |
72 |
> |
73 |
> Yeah... no. Slowing down the main manager for a thereotical edge |
74 |
> case doesn't seem particularly useful to me ;) |
75 |
|
76 |
...or you could just fix Python. |
77 |
|
78 |
-- |
79 |
Ciaran McCreesh |