Hi list, 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. 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/x86_64-pc-linux-gnu-gcc-5.1 /usr/x86_64-pc-linux-gnu/bin/i686-pc-linux-gnu-gcc-5.1 /usr/x86_64-pc-linux-gnu/bin/gcc-5.1 -> x86_64-pc-linux-gnu-gcc-5.1 /usr/x86_64-pc-linux-gnu/libexec/paludis/exheres-0/banned/gcc-5.1 Provided by gcc:6 /usr/x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu-gcc-6 /usr/x86_64-pc-linux-gnu/bin/i686-pc-linux-gnu-gcc-6 /usr/x86_64-pc-linux-gnu/bin/gcc-6 -> x86_64-pc-linux-gnu-gcc-6 /usr/x86_64-pc-linux-gnu/libexec/paludis/exheres-0/banned/gcc-6 Provided through alternatives: /usr/x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu-gcc -> x86_64-pc-linux-gnu-gcc-5.1 /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 future. 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 _______________________________________________ Exherbo-dev mailing list [email protected] http://lists.exherbo.org/mailman/listinfo/exherbo-dev
