Re: [gentoo-dev] Gentoo Council Reminder for May 28

[Patrick Lauer]

On Thursday 28 May 2009 21:52:49 Ciaran McCreesh wrote:
> On Thu, 28 May 2009 21:46:48 +0200
>
> Patrick Lauer <patrick@g.o> wrote:
> > > And just how do you plan to enforce that? What measures will you
> > > take to ensure that there's no way for developers or users to
> > > modify the repository?
> >
> > I can think of many simple methods. Like a tarball with a checksum.
>
> ...which a user can modify once it's been extracted.
>
> > Or a zipfile.
>
> ...which a user can modify once it's been extracted.
>
> > Or a git repository.
>
> ...which a user can commit to without telling the package manager that
> the cache is now invalid.

So, basically, we can't do anything, because the universe might spontaneously 
decide to cease to exist. Quite scary, that. 

Oh, and if you break stuff it is broken. Splendid!

Your random distraction at least made me giggle, but it is not relevant to the 
discussion of a readonly repository. 

>
> > That's all implementation details. But I think we can agree without
> > too much pain that it is possible to have a reasonably tamper-proof
> > format that we can consider readonly for these purposes.
>
> No, I do not in the slightest bit agree that there is an easy way of
> ensuring that what the package manager sees hasn't been tinkered with
> by a user or developer who "just wants to try a quick change out".

So things blow up. Sometimes Darwin has to do his work, especially when you 
climb over two fences, break open a locked metal door and discover that the 
Ursus arctos is, in fact, a very antisocial carnivore and not as cuddly as you 
thought.

You cannot stop a determined user from painting himself in a corner, but you 
can avoid most cases of accidental damage. 

>
> > > We can't make changes because the package manager needs to know the
> > > EAPI in order to parse versions, since once we make changes versions
> > > will be defined in terms of EAPI.
> >
> > ... why? You're stating one possible scenario as the only potential
> > solution again. That ignores the other methods that were mentioned on
> > this mailinglist and in other places where you lurk. Please stop
> > being so dishonest.
>
> No-one has provided a viable way of extending the version format that
> doesn't require EAPI changes. So unless you're talking about your
> "start a whole new tree" idea,
Wait, I thought noone had provided a way ... except that one ... argh, 
cognitive dissonance detected. 

I'm sorry, you contradicted yourself. Please choose one option only.

> which has already been debunked to
> death...
Weird, that didn't happen in this universe. 

> > > We want to make changes because, as has been stated several times
> > > previously, allowing 1.1_rc1 but forbidding 1.1-rc1 is entirely
> > > silly and arbitrary.
> >
> > See Intercal versioning. Also silly and arbitrary to avoid it, but
> > noone has provided a proposal to accomodate nonincreasing and
> > nonmonotonic versioning systems. I doubt you would want those allowed.
>
> No-one is suggesting making changes to match silly upstream versions.
But I thought you just said that silly and arbitrary restrictions ... I am 
confused. You are in a quantum superposition state where you support both 
sides of an argument and only collapse your brainwave functions whenever 
someone tries to observe you or something ... 

> What we are suggesting is making changes to match sensible and
> reasonable upstream versions.
Which we already have. Excellent, so you agree that we don't need to change 
versioning. Sometimes I really like discussing with you, because after a long 
time you suddenly accept reason :)