Re: [gentoo-project] Questions for candidates for Gentoo Council 2013/2014

[Ciaran McCreesh]

On Mon, 1 Jul 2013 21:56:02 +0200
Arfrever Frehtes Taifersar Arahesis <arfrever.fta@×××××.com> wrote:
> > The following should be treated with extreme caution, have unobvious
> > implications, need substantial work or are otherwise probably more
> > dangerous than they're worth, especially if we want EAPI 6 this
> > year:
> >
> > > 08. Will you vote for including support for version ranges in
> > > EAPI 6 (assuming that a patch is available for Portage)?
>
> Already implemented in Paludis (not in official EAPIs).
> Is it a mistake that Paludis supports this feature?

For users, it's useful. But EAPIs have nothing to do with user-facing
features, and Paludis does not support this feature in a Gentoo EAPI.
There needs to be a discussion and policy on how exactly they're allowed
to be used if they're permitted in the tree.

> Already implemented in Portage (not in official EAPIs).

This as an argument for a feature is wrong in at least three ways.

Firstly, an implementation is sometimes necessary to see why something
isn't as good an idea as it initially looks.

Secondly, there's a big difference between having something implemented
in a package mangler, and having experience with that feature in the
tree. Being able to implement something is a necessary condition, not a
sufficient one.

Thirdly, an implementation of a feature for users is not the same as
allowing it in the tree.

Repository dependencies are a good example of all three of these
points. For users, they're useful (although the limited way Portage has
them implemented removes a lot of that). But in the tree they have
problems that we know about (see previous discussions that you like to
ignore when pushing for this feature) and probably some that we don't
too, since no-one's ever tried using them in the tree. We've already
established that repository dependencies in the tree are the wrong
solution, so you using "there's an implementation!" in their favour is
at best disingenuous.

> > The following proposals are very bad, and implementing them would
> > be a mistake:
> >
> > > 11. Will you vote for providing master_repositories(),
> > > repository_path(), available_eclasses(), eclass_path() and
> > > license_path() functions in EAPI 6 (assuming that a patch is
> > > available for Portage)?
>
> This feature provides multiple-repository-friendly replacement for
> single-repository-specific PORTDIR and ECLASSDIR variables.
> Already implemented in Portage (not in official EAPIs).

The point of abolishing location variables is to allow things like
partial syncs, not to replace them with a slightly different thing that
imposes the same restrictions.

But again, if you're trying to advocate for any particular feature, you
should really discuss them on the relevant bugs, not try to use the
Council elections to subvert the process.

-- 
Ciaran McCreesh