Re: [gentoo-dev] Re: [RFC] multilib-build.eclass and restricting unsupported ABIs

[Michał Górny]

On Thu, 7 Mar 2013 17:25:23 +0100
Alexis Ballier <aballier@g.o> wrote:

> On Mon, 4 Mar 2013 21:49:48 +0100
> Michał Górny <mgorny@g.o> wrote:
>
> > I'm afraid that's the first potential point of failure. Relying
> > on argv[0] is a poor idea and means that any application calling
> > exec() with changed argv[0] on a wrapped binary will fail terribly.
>
> Go tell that to those that wrote busybox, tex or git: They all use
> that argv trick :) I'm sure there are plenty of other examples and
> don't consider that a poor idea. Note that the wrapper does not lie on
> argv: it just makes the binary think it has its original name (by
> passing argv as is) while it has been moved to allow parallel
> installation of different flavors of it.

We're talking about two different tricks.

Busybox checks argv to support symlinking for a standard tool. With
invalid argv[0], it still runs as the standard busybox binary. You can
use it that way, the 'safe way'.

Unless I'm missing something, git checks argv to support symlinking
into a few dozen tools which is optional. I doubt most of our users
rely on that rather than using the 'git foo' syntax.

A wrapper needs valid argv[0] to find the actual executable. Since
argv[0] is unlikely to contain a path, that's either reinventing some
logic or execvp() which is a bit fragile. Plus symlink resolution loop.
Hard links do not work at all.

And that's just theory. I may be missing some of the dangers.

> > I'm afraid you are actually starting to go the other way.
> >
> > Global wrapper means that it is potentially useful to our users.
> > However I don't really see people who want to compile 32-bit
> > executables think of setting some custom variable like ABI.
>
> They will not: Users will call the name-suffixed version directly. If
> they call the non-suffixed version then the above logic will run the
> DEFAULT_ABI version. There's no variable to set.

So there's no benefit from the wrapper to the users. We're talking
about a solution which is purely disadvantageous to them.

> The variable is more so that ebuilds/eclasses can set the variable and
> be done. Exactly like EPYTHON I think.

Python is almost a completely different issue. Most importantly, we
support multiple Python versions, and have to maintain all of them.
That support is extended to all packages in the tree, and is achieved
with no major losses.

We're talking about having multilib for a few chosen packages, and yet
introducing a tree-wide solution to hack-around even less of them.
A hack-around which has visible disadvantages.

> [...]
> > > That's why I asked for examples :)
> > > qmake may do it, I don't think its sane, but that's life for now.
> > > having glxinfo for each abi is useful from a user perspective (it
> > > does not need the wrapper a priori though)
> >
> > Yep, I intended to just have the additional variant of glxinfo
> > directly callable, with a name chosen specifically by the X11 team.
> > Wrapper would be more confusing than beneficial here IMO.
>
> Having a wrapper or not, for the end user that does not know the
> internal variable name, the end-result will be exactly the same :)

Unless he symlinked the tool. Then it simply won't work for him anymore.

> This is an extreme and stupid example, but without any wrapper and with
> ABI-specific output used within ebuilds and build systems, you have to
> be *very* careful that the correct tool is *always* called.
> The wrapper is only a way to ensure that after all :)

The main point is to enforce ebuild developers to be careful while
handling multilib. This is the main difference from Tommy's solution --
I don't want people to switch the 'multilib' flag on ebuilds
thoughtlessly and expect everything to work without changing the ebuild.

-- 
Best regards,
Michał Górny