1 |
On Mon, Nov 23, 2009 at 11:49:25AM -0700, Denis Dupeyron wrote: |
2 |
> 2- Here's the second idea, shamelessly pasted (note that it says EAPI4 |
3 |
> below instead of EAPI3 but this is irrelevant to the idea): |
4 |
> |
5 |
> "Thus, I would let EAPI 4 ebuilds call dopreservemtimes (with an API |
6 |
> similar to docompress) in both src_install and pkg_preinst. Doing so |
7 |
> would instruct the package manager that it must preserve mtimes |
8 |
> (including subsecond, if supported on the filesystem) for a particular |
9 |
> set of paths, even if doing so means no stripping etc. All other mtimes |
10 |
> may be rewritten as the package manager sees fit, and from EAPI 4 |
11 |
> onwards must be rewritten at merge time for anything predating the |
12 |
> start of the build." |
13 |
|
14 |
Someone mind explaining to me why we're making mtime preservation so |
15 |
nasty? Having to enumerate every pathway that requires mtime |
16 |
preservation is pretty arduous for the ebuild dev, meaning it's |
17 |
unlikely they'll get it right, leading to bugs. |
18 |
|
19 |
The thing I'm not understanding here is that pkgcore since day one has |
20 |
preserved mtime- I've yet to see any complaints about that nor any |
21 |
issues caused by it. Portage shifted over a year or two back, same |
22 |
thing, haven't heard complaints. |
23 |
|
24 |
The thing that's bugging me about this whole discussion is that we're |
25 |
spending more time focusing on stupid things the manager could do to |
26 |
(basically intentionally) screw up the mtime preservation. |
27 |
|
28 |
I know it won't fly, but realistically stating "the package manager |
29 |
must preserve mtime- if there are instances where it does not (due to |
30 |
some feature, perhaps splitdebug or some form of compression) it is |
31 |
the package managers responsibility to ensure this does not break the |
32 |
ebuilds resultant merge/runtime invocation". |
33 |
|
34 |
Via such wording an exemption is created and it's made clear it's the |
35 |
managers responsibility to keep things playing nice... if the manager |
36 |
can't do that, then the feature/functionality that is changing the |
37 |
mtime (resulting in the pkg on disk failing) must be fixed or |
38 |
disabled. |
39 |
|
40 |
The nice thing about this wording is that it basically matches what |
41 |
the case is now, and what has worked for quite a few years. |
42 |
|
43 |
|
44 |
> In both cases nanosecond resolution may be required and is a problem |
45 |
> due to python. The following workaround can be used until the |
46 |
> nanosecond issue is fixed in python: |
47 |
|
48 |
It'd be nice if someone enumerated merge scenarios where nanosecond |
49 |
resolution is actually required. Seems like a white elephant to me, |
50 |
especially in combination w/ the fact that the target fs may not |
51 |
support nanosecond. |
52 |
|
53 |
Basically, if it's required the manager support nanosecond resolution |
54 |
for merging, ebuilds must be able to rely on that- end result, any |
55 |
merging to FS's that do not support nanosecond (this includes the |
56 |
intermediate ${D}) are no longer supported. Unless I'm missing |
57 |
something, iso-9660 doesn't look to support nanosecond resolution. |
58 |
Beyond that, does cramfs/squashfs? If not, taking this to the |
59 |
logical conclusion the livecds aren't technically supported as a merge |
60 |
environment. |
61 |
|
62 |
Essentially If we're going to require the manager support NS |
63 |
resolution w/out requiring all FS's involved support NS level |
64 |
resolution, in reality ebuilds can't rely on NS level resolution. |
65 |
|
66 |
Thus drop the requirement since we gain nothing from it- if it's not a |
67 |
gurantee ebuilds can rely on then they should be writing to the lowest |
68 |
common denominator- second level resolution. That may sound heinous, |
69 |
but it's also being realistic. |
70 |
|
71 |
|
72 |
> "Alternatively, we could simply make portage spawn the mv binary |
73 |
> whenever rename fails (it fails when the source and destination are |
74 |
> on different devices). Although it's relatively slow, it should |
75 |
> solve the problem." |
76 |
|
77 |
Yeah... no. Slowing down the main manager for a thereotical edge case |
78 |
doesn't seem particularly useful to me ;) |
79 |
|
80 |
~harring |