1 |
Potentially just being a tool and taking the bait.. |
2 |
|
3 |
On Thu, Nov 26, 2009 at 12:41:55PM +0000, David Leverton wrote: |
4 |
> 2009/11/26 Brian Harring <ferringb@×××××.com>: |
5 |
> > Why is this one special? Two out of three do this already, and it |
6 |
> > works. |
7 |
> |
8 |
> You mean "two out of three blatently ignored long-standing behaviour |
9 |
> and added a new feature without discussion or an EAPI bump". |
10 |
|
11 |
It was always on the todo to convert portage over to preserving mtime- |
12 |
this long predates PMS and even EAPI. |
13 |
|
14 |
This stretches all the way back to '03/'04. I'll also note that |
15 |
pkgcore from the getgo preserved mtime, back when it was called |
16 |
'portage'. Ahh, the good old days before svn pissed me off enough to |
17 |
move it outside of gentoo. |
18 |
|
19 |
Beyond that, I presume your intention is to stir things up- PMS went |
20 |
out of it's way to explicitly leave it up to the manager if they |
21 |
preserve mtimes. Meaning portage hasn't done anything wrong in |
22 |
changing it's behaviour. |
23 |
|
24 |
It's a bit ironic really. Y'all didn't want mtime in there so it was |
25 |
left unspecified. Now you're complaining that portage changed it's |
26 |
behaviour (2+ years after the fact) as an arguement against adding |
27 |
mtime preservation into the next eapi. |
28 |
|
29 |
|
30 |
> > Paludis doesn't preserve mtime |
31 |
> |
32 |
> You mean "Paludis carefully emulated Portage behaviour, and is now |
33 |
> somehow being blamed for the whole matter, to the extent that people |
34 |
> are trying to use threats (to the effect of 'I'm going to deliberately |
35 |
> break packages for Paludis users") to try to get their way in the |
36 |
> discussion". |
37 |
|
38 |
I mean paludis doesn't preserve mtimes. People aren't going out of |
39 |
their way to break paludis (and claiming so is just trolling). |
40 |
|
41 |
Breakages happen because the common sense assumption devs have |
42 |
(preservation of mtime) aren't actually encoded as a format standard. |
43 |
Further, there are quite a few postinst hacks (and quite a few that |
44 |
don't work all that well) working around the lack of mtime |
45 |
preservation. |
46 |
|
47 |
|
48 |
> > and it's approach to randomly resetting mtimes |
49 |
> |
50 |
> There's nothing random about it. Files' mtimes are reset to the |
51 |
> current time while being merged, just as Portage did for years. |
52 |
|
53 |
Just because portage did something for a few years, does not make it |
54 |
right (this is something the PMS folk have been claiming since day |
55 |
one). So... that arguement is invalidated by your own statements. |
56 |
|
57 |
I label it as 'randomly' due to the fact it's contrary to what ebuild |
58 |
developers expect- it was a flaw when portage was doing it, it's a |
59 |
flaw that paludis does it due to it unnecessarily creating a gotcha |
60 |
for ebuild developers. Most importantly, no one has brought up a |
61 |
single instance of mtime preservation *breaking* things- the only |
62 |
criticism leveled has been ciaranms aesthetic complaints about |
63 |
ca-certificates and older timestamps making their way to the FS. |
64 |
Hence labeling it unnecessarily. |
65 |
|
66 |
|
67 |
Basically, y'all need to provide actual examples of this causing |
68 |
issues- right now the responses are either quite flammable, or lacking |
69 |
in technical arguements. More obstructionist then useful for a |
70 |
technical discourse. |
71 |
|
72 |
~harring |