1 |
On Wed, 25 Nov 2009 17:28:33 -0800 |
2 |
Brian Harring <ferringb@×××××.com> wrote: |
3 |
> > It's not in the least bit nasty. It's requiring people to be |
4 |
> > explicit about special requirements. |
5 |
> |
6 |
> I honestly wish that explicitness you're pushing for mtime were |
7 |
> applied to all parts of mtime. |
8 |
> |
9 |
> Why is this one special? Two out of three do this already, and it |
10 |
> works. Paludis doesn't preserve mtime- and it's approach to randomly |
11 |
> resetting mtimes is known to cause issues (bug 263387, python eclass |
12 |
> having to do pyc/pyo compilation in postinst, etc). |
13 |
|
14 |
No, two out of three do a half-arsed job about it. If we're going to |
15 |
make it behaviour upon which packages can rely, we should be doing so |
16 |
properly to avoid the whole mess cropping up again as people start |
17 |
following the newer POSIX standard. |
18 |
|
19 |
> > You can't have been listening very hard, then. The complaint is |
20 |
> > that it results in files with dumb mtimes being merged to /. |
21 |
> |
22 |
> As far as I can tell, no one but you is complaining about the |
23 |
> mtimes. |
24 |
> |
25 |
> Your complaints primarily have been that tarball'd mtimes can pass |
26 |
> through to the fs- I've not seen any comments from you in bug 264130 |
27 |
> that actually enumerate spots were this is anything but an aesthetic |
28 |
> complaint. Specifically your aesthetics- the pkgs in question have |
29 |
> functioned fine w/ odd mtimes passing through. |
30 |
|
31 |
Yes, again, it's about doing it properly. |
32 |
|
33 |
> > Wording such as that just isn't suitable for a specification. It |
34 |
> > requires implementers to guess what future ebuilds are going to |
35 |
> > rely upon (and ebuilds regularly do rely upon weird quirks), and |
36 |
> > makes it impossible to produce a package manager that can be shown |
37 |
> > to be compliant. |
38 |
> |
39 |
> That wording is explicit that PMS cannot lock down all potentials. |
40 |
|
41 |
Ok, so PMS would effectively say "ebuilds must not rely upon any |
42 |
particular behaviour", which in turn means any ebuild that breaks with |
43 |
older Portage / Paludis is broken. That's not what you're after, is it? |
44 |
|
45 |
> This is no different then PMS's stance on VDB (and similar in |
46 |
> reasoning)- ebuilds are reliant on vdb internals yet PMS explicitly |
47 |
> ducked documenting it. Double standards suck. |
48 |
|
49 |
That one's being fixed, slowly... |
50 |
|
51 |
> Further, drop the specificity BS. You've intentionally left parts of |
52 |
> PMS vague- trailing '/' for ebuild vars is a good example (ssmtp |
53 |
> breaks if ${D} vs ${D}/, perl likely has the same breakage). These |
54 |
> lead to actual incompatibilities, and because PMS isn't explicit, |
55 |
> there is no 'right' implementation for it. |
56 |
|
57 |
These are entirely unrelated. Any ebuild that relies upon the slash |
58 |
either way is broken. But we can't realistically do that for mtimes, |
59 |
since it would involve modifying *the package that gets installed*, and |
60 |
doing so by patching sources to use things POSIX considers deprecated. |
61 |
It's not just an ebuild tweak. |
62 |
|
63 |
> The daft thing about you picking at this wording is that the |
64 |
> scenarios you can come up with are all hypothetical. Yes, a manager |
65 |
> could randomize mtimes when it's doing splitdebug. |
66 |
> |
67 |
> The manager wouldn't however because the only reason to do things |
68 |
> like that is to intentionally cause issues. |
69 |
|
70 |
It's about doing it right, so we don't get bitten by it later on when |
71 |
everyone's using nanosecond-resolution timestamps like POSIX suggests. |
72 |
|
73 |
-- |
74 |
Ciaran McCreesh |