1 |
On Thursday 28 May 2009 21:26:43 Ciaran McCreesh wrote: |
2 |
> On Thu, 28 May 2009 21:19:35 +0200 |
3 |
> |
4 |
> Patrick Lauer <patrick@g.o> wrote: |
5 |
> > You know, usually snipping away everything else is a bit evil because |
6 |
> > it removes context, but in this case I just want to point out one or |
7 |
> > two little pieces ... |
8 |
> |
9 |
> Because you know fine well I'm right, but want to carry on trying to |
10 |
> derail progress? |
11 |
|
12 |
That's an interesting concept. But you know as well as I do that it isn't so, |
13 |
thus we have to classify your statement as a mediocre trolling attempt. Bonus |
14 |
for the anticipated emotional response, but I hope you're not too upset when I |
15 |
don't satisfy you with some mindless flaming. This mailinglist just isn't the |
16 |
right place for it ... |
17 |
|
18 |
|
19 |
> > > > For example a readonly repository would guarantee that the cache |
20 |
> > > > is always consistent. |
21 |
> > > |
22 |
> > > Until someone modifies it, yes. |
23 |
> > |
24 |
> > Well. DUH. That's why it is readonly. Otherwise it wouldn't be |
25 |
> > readonly. |
26 |
> |
27 |
> And just how do you plan to enforce that? What measures will you take |
28 |
> to ensure that there's no way for developers or users to modify the |
29 |
> repository? |
30 |
I can think of many simple methods. Like a tarball with a checksum. Or a |
31 |
zipfile. Or a git repository. That's all implementation details. But I think |
32 |
we can agree without too much pain that it is possible to have a reasonably |
33 |
tamper-proof format that we can consider readonly for these purposes. |
34 |
And automatically creating it is not much different from generating rsync |
35 |
snapshots now. I guess, smart as you are, you knew that already. |
36 |
|
37 |
> We can't make changes because the package manager needs to know the |
38 |
> EAPI in order to parse versions, since once we make changes versions |
39 |
> will be defined in terms of EAPI. |
40 |
... why? You're stating one possible scenario as the only potential solution |
41 |
again. That ignores the other methods that were mentioned on this mailinglist |
42 |
and in other places where you lurk. Please stop being so dishonest. |
43 |
|
44 |
|
45 |
> We want to make changes because, as has been stated several times |
46 |
> previously, allowing 1.1_rc1 but forbidding 1.1-rc1 is entirely silly |
47 |
> and arbitrary. |
48 |
See Intercal versioning. Also silly and arbitrary to avoid it, but noone has |
49 |
provided a proposal to accomodate nonincreasing and nonmonotonic versioning |
50 |
systems. I doubt you would want those allowed. |
51 |
|
52 |
> > > > It would help if you would tolerate other opinions (or even the |
53 |
> > > > possibility that other people may have opinions that do not agree |
54 |
> > > > with you). |
55 |
> > > |
56 |
> > > The only issue of opinion is whether or not .ebuild-X and .eapi-X.eb |
57 |
> > > look pretty. The rest is purely technical and entirely objective. |
58 |
> > |
59 |
> > I think I have pointed you a few times at objective statements |
60 |
> > disagreeing with your subjective opinion. I hate repeating myself. |
61 |
> |
62 |
> And yet you keep ignoring the part where GLEP 55 demonstrates |
63 |
> objectively that the extension solution is better than the alternatives. |
64 |
|
65 |
I really. Really. Hate repeating myself. |
66 |
It's so redundantly superfluously redundant. And it wastes people's time. Did |
67 |
I mention it is redundant? |