On Thu, Mar 17, 2016 at 08:29:51PM +0100, Wouter van Kesteren wrote: > 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 happy. [...] > 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.
Sounds good to me. [...] > 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 future. If we exec banned_in_eapi_exheres-0, does banned_in_eapi_exheres-0 actually have a clue what called it? Has anybody tested this in practise? > 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? dobanned doesn't sound useful given that the implementation will sometimes be installed and sometimes be provided by an alternative. dobanned would only support the former, I think. BANNEDDIR does sound useful. [...] The other thing that hasn't been covered particularly well here is how to create the actual unprefixed executables. Originally I thought I'd just create an alternative for all of them, but then I realised that the things we lack unprefixed executables for consist of things from five different toolchain packages and a dozen alternatives or whatever. But I was also overcomplicating this, because an unprefixed executable for gcc on native amd64 needs to go in /usr/x86_64-pc-linux-gnu/bin/ while a gcc for x86 needs to go in /usr/i686-pc-linux-gnu/bin/ etc. /usr/bin/gcc will then just point at whichever of these directories /usr/host points at without further complications. This all results in the fairly straight-forward solution implemented for binutils and pkg-config in: https://galileo.mailstation.de/gerrit/#/c/5519/ https://galileo.mailstation.de/gerrit/#/c/5518/ More to come for gcc et al. So the crux of it is that the unprefixed executable gets installed by whatever installed the prefixed executable whenever host and target are the same. -- Bo Ørsted Andresen _______________________________________________ Exherbo-dev mailing list [email protected] http://lists.exherbo.org/mailman/listinfo/exherbo-dev
