| 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? |
Archives