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

[Michał Górny]

On Sun, 2 Sep 2012 17:51:00 +0200
Fabio Erculiani <lxnay@g.o> wrote:

> On Sun, Sep 2, 2012 at 5:23 PM, Michał Górny <mgorny@g.o>
> wrote:
> > On Sun, 2 Sep 2012 17:09:22 +0200
> > Fabio Erculiani <lxnay@g.o> wrote:
> >
> >> On Sun, Sep 2, 2012 at 4:57 PM, hasufell <hasufell@g.o>
> >> wrote:
> >> >
> >> >
> >> > Why not introduce a global useflag such as "suggested-deps" which
> >> > complies with GLEP 62 meaning it will be in IUSE_RUNTIME.
> >> >
> >>
> >> How do you manage to fix the PDEPEND "identity disorder" problem
> >> then? Teaching devs to move to GLEP 62 is much harder than just
> >> telling them to move dep strings to more appropriate locations.
> >
> > Much harder? So, devs today don't know how USE flags work? Or do you
> > implying that devs should know bare technical details of package
> > manager implementation? Or is it just an-ass argument to support
> > an ass-thesis?
>
> For instance, the amount of devs still improperly using pkg_setup for
> build-time stuff, after years that they've been told to not do that,
> is a good example of how, while we're great, we tend to be resilient
> to change. This goes beyond software engineering, this is about
> psychology. The more one thing is simple, the faster is recognized and
> properly used by people.
>
> Not to mention that I am one of the PMS writers here (Entropy cough),
> and I know how much harder implementing runtime-switchable USE flags
> is, compared to a simple SDEPEND solution.

Yes, I'm aware of that. You're trying to force a worse solution because
it is easier for you to implement in your partial package manager.

> >> Moreover, your solution just makes the USE flags abuse situation
> >> worse: there are packages that use USE flags just to include extra,
> >> optional packages in the dependencies... See USE=bluetooth in
> >> net-misc/networkmanager for example (this is what I mean with USE
> >> flags abuse, actually).
> >
> > No, it fixes it. It enables those packages to use the same solution,
> > fixing its downsides.
>
> It looks like it just tries to workaround the issue, not fix it to its
> roots (PDEPEND is ill!).

It is invalid to use those packages in PDEPEND; even Ciaran will tell
you that.

> >> I'm not saying that SDEPEND is the best one-size-fits-all solution
> >> but you may agree that's the simplest and most effective one.
> >
> > pkg_postinst() is simpler. USE flags are simple and very effective,
> > yet incorrect.
>
> Could you tell me how would you plan to implement so API to read
> "suggested" dependencies from pkg_postinst() output?
> I understand that being API-friendly is not really the best feature of
> Portage and ebuilds in general (one reason why our PackageKit backend
> is a bit sucky) but this is not a good reason to keep doing things
> like they've been always done.
> (Information printed at pkg_postinst() is another interesting problem,
> wrt API consumers, and this includes PackageKit, but I don't want to
> drift away too much from the topic).
>
> >
> > An effective SDEPEND implementation is definitely nowhere close
> > to simple. Nor is presenting those dependencies to users.
>
> As I mentioned above, I know what it simple and what not, from a
> Software Engineering point of view. And SDEPENDs are much simpler than
> GLEP 62, and GLEP 62 does not fix the PDEPEND issue because
> individuals will keep using it because at the end of the day, it is
> order of magniture simpler than obscure new variables and USE flags.
> As a rule of thumb, "simple" always shines over the complex and
> convoluted in the long run.

As long as it's complete. A simple incomplete solution is yet another
hack which will have to be worked-around in the future again. And
you'll end up with 5 different solutions which will have to somehow
work together to solve a single problem (see: exheres).

-- 
Best regards,
Michał Górny