List Archive: gentoo-pms
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
On Sun, 20 Sep 2009 01:07:25 +0200
Patrick Lauer <email@example.com> wrote:
> > Ulrich Mueller <firstname.lastname@example.org> wrote:
> > > >>>>> On Sat, 19 Sep 2009, Ciaran McCreesh wrote:
> > > > But it was an official Gentoo project, [...]
> > >
> > > The 2008-04-10 council summary says something different:
> > >
> > > # The council voted that kdebuild-1 and other unapproved EAPIs
> > > could # not be in an approved PMS document. The spec isn't a
> > > place for # proposals or things that will never be submitted for
> > > approval by the # council. It's a specification, a reference of
> > > what is allowed in the # main tree.
> > Please point to where the Council said that the Gentoo KDE project
> > wasn't an official Gentoo project.
> That is unrelated to the matter. Please stop trying to confuse the
> discussion when you run out of arguments.
I made a claim, and Ulrich said that the Council disagreed. But the
decision he points to does not contradict the claim I made. It's
> The council statement is VERY clear and unambiguous. What other
> gentoo projects do on the side is their thing and not directly
> related to PMS (unless you intend to have the prefix project merge
> all their changes and new EAPIs into PMS?)
Sure. If the prefix project can put together a specification-quality
description of their work, and can guarantee the level of stability
that we need from EAPIs, I'd be happy to see it in PMS. It would be much
more useful for package manager authors to have it documented and well
> > > So, really no need to discuss it further.
> > Sure there is. Let's look at what happens if you remove it:
> > * It makes it harder for package manager authors to deal with things
> > that were delivered by an official Gentoo project.
> Then they need to read that project's documentation. The genkdesvn
> project is free to split out their own PMS+kdebuild-1 fork.
Forks are a last resort. For package manager authors, having a single
source rather than two is much easier, and if it's possible to do
things that way then we should. Forks should only happen when there's
no other way of resolving it.
Why should we make PMS less useful for package manager developers?