1 |
On Tue, Nov 24, 2009 at 10:21:06PM +0000, Ciaran McCreesh wrote: |
2 |
> On Mon, 23 Nov 2009 15:19:00 -0800 |
3 |
> Brian Harring <ferringb@×××××.com> wrote: |
4 |
> > Someone mind explaining to me why we're making mtime preservation so |
5 |
> > nasty? Having to enumerate every pathway that requires mtime |
6 |
> > preservation is pretty arduous for the ebuild dev, meaning it's |
7 |
> > unlikely they'll get it right, leading to bugs. |
8 |
> |
9 |
> It's not in the least bit nasty. It's requiring people to be explicit |
10 |
> about special requirements. |
11 |
|
12 |
I honestly wish that explicitness you're pushing for mtime were |
13 |
applied to all parts of mtime. |
14 |
|
15 |
Why is this one special? Two out of three do this already, and it |
16 |
works. Paludis doesn't preserve mtime- and it's approach to randomly |
17 |
resetting mtimes is known to cause issues (bug 263387, python eclass |
18 |
having to do pyc/pyo compilation in postinst, etc). |
19 |
|
20 |
|
21 |
> > The thing I'm not understanding here is that pkgcore since day one |
22 |
> > has preserved mtime- I've yet to see any complaints about that nor |
23 |
> > any issues caused by it. Portage shifted over a year or two back, |
24 |
> > same thing, haven't heard complaints. |
25 |
> |
26 |
> You can't have been listening very hard, then. The complaint is that it |
27 |
> results in files with dumb mtimes being merged to /. |
28 |
|
29 |
As far as I can tell, no one but you is complaining about the mtimes. |
30 |
|
31 |
Your complaints primarily have been that tarball'd mtimes can pass |
32 |
through to the fs- I've not seen any comments from you in bug 264130 |
33 |
that actually enumerate spots were this is anything but an aesthetic |
34 |
complaint. Specifically your aesthetics- the pkgs in question have |
35 |
functioned fine w/ odd mtimes passing through. |
36 |
|
37 |
|
38 |
> > I know it won't fly, but realistically stating "the package manager |
39 |
> > must preserve mtime- if there are instances where it does not (due to |
40 |
> > some feature, perhaps splitdebug or some form of compression) it is |
41 |
> > the package managers responsibility to ensure this does not break the |
42 |
> > ebuilds resultant merge/runtime invocation". |
43 |
> > |
44 |
> > Via such wording an exemption is created and it's made clear it's the |
45 |
> > managers responsibility to keep things playing nice... if the manager |
46 |
> > can't do that, then the feature/functionality that is changing the |
47 |
> > mtime (resulting in the pkg on disk failing) must be fixed or |
48 |
> > disabled. |
49 |
> > |
50 |
> > The nice thing about this wording is that it basically matches what |
51 |
> > the case is now, and what has worked for quite a few years. |
52 |
> |
53 |
> Wording such as that just isn't suitable for a specification. It |
54 |
> requires implementers to guess what future ebuilds are going to |
55 |
> rely upon (and ebuilds regularly do rely upon weird quirks), and makes |
56 |
> it impossible to produce a package manager that can be shown to be |
57 |
> compliant. |
58 |
|
59 |
That wording is explicit that PMS cannot lock down all potentials. |
60 |
This is no different then PMS's stance on VDB (and similar in |
61 |
reasoning)- ebuilds are reliant on vdb internals yet PMS explicitly |
62 |
ducked documenting it. Double standards suck. |
63 |
|
64 |
Further, drop the specificity BS. You've intentionally left parts of |
65 |
PMS vague- trailing '/' for ebuild vars is a good example (ssmtp |
66 |
breaks if ${D} vs ${D}/, perl likely has the same breakage). These |
67 |
lead to actual incompatibilities, and because PMS isn't explicit, |
68 |
there is no 'right' implementation for it. |
69 |
|
70 |
The daft thing about you picking at this wording is that the scenarios |
71 |
you can come up with are all hypothetical. Yes, a manager could |
72 |
randomize mtimes when it's doing splitdebug. |
73 |
|
74 |
The manager wouldn't however because the only reason to do things like |
75 |
that is to intentionally cause issues. |
76 |
|
77 |
~brian |