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