Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Ciaran McCreesh <ciaran.mccreesh@...>
Subject: Re: Gentoo Council Reminder for May 28
Date: Thu, 28 May 2009 20:52:49 +0100
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.

> 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".

> > 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, which has already been debunked to
death...

> > 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.
What we are suggesting is making changes to match sensible and
reasonable upstream versions.

-- 
Ciaran McCreesh
Attachment:
signature.asc (PGP signature)
Replies:
Re: Gentoo Council Reminder for May 28
-- Patrick Lauer
References:
Re: Gentoo Council Reminder for May 28
-- Tiziano Müller
Re: Gentoo Council Reminder for May 28
-- Patrick Lauer
Re: Gentoo Council Reminder for May 28
-- Ciaran McCreesh
Re: Gentoo Council Reminder for May 28
-- Patrick Lauer
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Gentoo Council Reminder for May 28
Next by thread:
Re: Gentoo Council Reminder for May 28
Previous by date:
Re: Gentoo Council Reminder for May 28
Next by date:
Re: Gentoo Council Reminder for May 28


Updated Jun 17, 2009

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.