[Exherbo-dev] [RFC] Unprefixed executables.
Wouter van Kesteren
woutershep at gmail.com
Thu Mar 17 19:29:51 UTC 2016
It's well known that people want unprefixed executables (gcc, ld,
pkg-config and friends) so that we for example don't break people
their `./configure && make` and avoid having to resort to weird
BUILDCC arguments to build the linux kernel. However we don't want
these to be usable from inside of exheres because we value correctness
over easiness there.
We talked on and off about this on irc for a while now and we believe
we have found a general and extendable solution that makes everyone
First a bit of backstory: We realised that there needs to be a list of
executables we need to ban somewhere. We gave thought to two locations
where we can put this list.
1. We can put this list in paludis, which has a massive downside of
needing to change and release a new paludis every time we want to ban
an additional tool.
2. We can put this list in some configuration file like the profiles,
which means we end up with a big list there of all imaginable
unprefixed things we want to ban in there instead.
Then moben suggested the novel idea: lets have the packages themselves
decide what they want to ban. The talking that followed after that led
to this proposal.
We want to designate a special directory (for the sake of this
document lets say $libexec/paludis/exheres-0/banned/ for now, to be
discussed) which packages can install to to shadow the real
executables. This directory will then be prepended to the PATH by
paludis, effectively banning the real executables. When executed these
fake executables will complain loudly and die.
This has several neat advantages, we don't have to release paludis all
the time for minor additions. We also don't end up with a huge list we
have to maintain in a single place. This means that its nice and
decentralized so that when cat/pkg::3rdparty installs an unprefixed
tool or gcc:7 introduces a new one they don't have to contribute a
patch to ::paludis or ::arbor to update the list. As a minor bonus it
also means we don't have have 'which gcj' return success in
paludis-context when gcj isn't even installed, because its only
shadowed the moment its actually installed.
It can also work nicely with multiple versions, here's a quick example
of how that might look for gcc:
Provided by gcc:5.1
/usr/x86_64-pc-linux-gnu/bin/gcc-5.1 -> x86_64-pc-linux-gnu-gcc-5.1
Provided by gcc:6
/usr/x86_64-pc-linux-gnu/bin/gcc-6 -> x86_64-pc-linux-gnu-gcc-6
Provided through alternatives:
/usr/x86_64-pc-linux-gnu/bin/i686-pc-linux-gnu-gcc -> i686-pc-linux-gnu-gcc-5.1
/usr/x86_64-pc-linux-gnu/bin/gcc -> gcc-5.1
/usr/x86_64-pc-linux-gnu/libexec/paludis/exheres-0/banned/gcc -> gcc-5.1
The files in the /banned/ directory could be either symlinks to
banned_in_eapi_exheres-0 or tiny wrappers like '#!/bin/sh' 'exec
banned_in_eapi_exheres-0', the latter of which is i think preferred
because it means we can freely relocate the implementation in the
There are a couple of things that would need further discussion from
this point, the main ones being:
1. what directory are we picking?
2. what will the implementation of the tiny ban scripts be?
3. do we want some helper like dobanned and/or env like BANNEDDIR
given by paludis and/or exlib?
Like what would happen when we finalize exheres-0 into exheres-1?
Maybe calling banned_in_eapi_exheres-0 isn't such a good idea? Also
given the fact we will have to support this path forever, even maybe
through another packagemanger, maybe /etc/env.d/banned-things/ or
something would be a better location than something containing
'paludis' and 'exheres-0'.
If anyone has any feedback on either the general idea or the
implementation details that still need to be sorted ( try not to
bikeshed all over the path ;) ) please send a reply.
- Wouter van Kesteren
More information about the Exherbo-dev