Re: [gentoo-dev] [RFC] EAPI 5+: split PDEPEND introducing SDEPEND

[Ciaran McCreesh]

On Sun, 2 Sep 2012 20:46:19 +0200
Fabio Erculiani <lxnay@g.o> wrote:
> On Sun, Sep 2, 2012 at 8:08 PM, Ciaran McCreesh
> <ciaran.mccreesh@××××××××××.com> wrote:
> > and we have worked out all the difficulties.
>
> Please elaborate. What difficulties? What did you implement other than
> plain SDEPEND? With what features? Lots of detail missing.

The big issues you're ignoring:

* What to do if a package has an SDEPEND upon cat/pkg[x] and the user
  has cat/pkg[-x] installed, or if another package in the resolution
  depends upon cat/pkg and the user hasn't specified USE=x. Similarly,
  an SDEPEND upon >=cat/pkg-2.1 and the user has cat/pkg-2.0 (which is
  in the same slot as 2.1) installed. The right answer is to force a
  reinstall with [x] / force the upgrade, and for the spec to
  explicitly require this from implementations, but *why* this is the
  case is fairly subtle.

* How to handle groups of dependencies in suggestions.

* How to display suggestions to the user, and allow the user to
  confirm or reject suggestions. From a spec perspective, we don't
  mandate any particular behaviour, but we do need to make sure that a
  good quality implementation is possible. With SDEPEND as you're
  proposing, we're going to have exactly the same issues we currently
  have with REQUIRED_USE and blockers: ebuilds won't provide enough
  information to provide a good user interface.

* What use? blocks in SDEPEND actually mean. Again, there's a right
  answer here: it's for when a particular suggestion requires the base
  package to be built in a particular way.

> > Having said that, if we're going with suggested dependencies for
> > EAPI 5 (which I strongly suspect won't happen, since we seem to be
> > wanting EAPI 5 now rather than in several years time...) then
> > there's a lot more to getting it right than is mentioned in the
> > original post, and it needs to be written up properly.
>
> Well, this depends on the quality of the PMS architecture, I am not
> familiar with Paludis tho.

Paludis already has it. The question is whether it can be implemented
for Portage.

> I don't remember to have listed anything about what needs to be done
> at the implementation level actually, nor I really wanted to.

That's a problem. You can't just magically describe a vague feature and
expect it to be implementable.

> I always use the 5 minutes "rule of thumb" strategy to understand the
> complexity of proposals: if it takes me more than 5 minutes to
> understand it, then users (!= devs) will have to go through the same
> or more "wtf-period". And the probability of them "giving up / getting
> sick / ignoring it" is linear with the wtf-period.

There's a big difference between understanding things for developers,
and getting it right for implementation. Where possible, users and
developers should only need a shallow understanding of a feature to be
able to use it, but for the purposes of the spec and the
implementation, we need a proper deep understanding of the topic, and
you aren't giving that.

-- 
Ciaran McCreesh