On Sun, 2 Sep 2012 20:46:19 +0200 Fabio Erculiani <lx...@gentoo.org> wrote: > On Sun, Sep 2, 2012 at 8:08 PM, Ciaran McCreesh > <ciaran.mccre...@googlemail.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
signature.asc
Description: PGP signature
