Re: [gentoo-dev] Deps on slotted executables (implicit @system tangent)

[Michał Górny]

Dnia 2014-11-14, o godz. 09:08:17
Michael Orlitzky <mjo@g.o> napisał(a):

> On 11/13/2014 10:17 AM, Ian Stakenvicius wrote:
>
> >> Isn't it possible to disable C++ in GCC with USE="-cxx"?
> >
> > It is..  but unfortunately there's no way in DEPEND to ensure it's
> > satisfied, as you can have a gcc installed with that flag enabled but
> > have a second one (that's actually selected in gcc-config) with it
> > disabled.  A pkg_pretend check or a pkg_setup check (if you don't want
> > it to just fail in src_configure) is probably the best way to enforce
> > that one at this time.  Unless there are other ways I'm not aware of??
>
> Is this a case (as was recently suggested) where we're doing something
> stupid rather than asking for help from the PMS? This problem shows up
> in a few places -- off the top of my head:
>
>   * GCC (see sys-apps/systemd-217.ebuild)
>   * PHP (see comment in app-text/XML-Schema-learner-1.0.0.ebuild)
>   * Python (all over the place)
>   * Ruby (all over the place)
>
> Since all of the above are slotted, we can DEPEND on them, but we can't
> actually be sure that we're using the right slot at build time. The
> package manager knows that the right version is there, but it's not at
> the moment prepared to find and use it.
>
> Question 1: is it desirable to e.g. switch compilers, compile systemd,
> and then switch back? At first I thought the PM should respect my
> selected compiler, but after thinking about it for a few minutes, I've
> changed my mind. The compiler deps are just like anything else: if I ask
> portage to install systemd, it should do what it takes to install
> systemd assuming I approve the build plan.

Relying on stuff that can be switched outside the PM scope is always
a bad idea. Think of eselect-opengl -- for a long time, people had to
switch the OpenGL implementation to xorg to build xorg server, and then
back to be able to use anything using OpenGL. Then we fixed xorg-server
to use the underlying headers directly.

I think we should use the same solution for the gcc issues. We already
expect packages to respect CC & CXX -- why not set them then? I'm
keeping my CC & CXX at a specific gcc version for a long time now.

-- 
Best regards,
Michał Górny