[gentoo-dev] Re: Add commit to pull request
On 6/21/20 7:48 PM, Samuel Bernardo wrote: > Hi, > > I need to add a commit to a gentoo pull request that I had opened before. > > https://github.com/samuelbernardo/gentoo > > Is it possible to add the commit to that pull request or I need to open > a new pull request? > > I already try to get help in gentoo-dev channel but I haven't voice there... > > Thanks > > Looking at your fork, you'll want to update your master branch (or whatever it's called nowadays) and create a new branch for every new pull request you make. #gentoo-dev-help IRC channel exists. -- juippis signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: News item: xorg-server dropping default suid
200621 Matt Turner wrote: > On Sun, Jun 21, 2020 at 4:53 PM Philip Webb wrote: >> I've been running xorg-server as root for > 16 yr without any problems. >> AFAIK there are no problems re exploits via I/net browsers, >> which are started by my user as all such user software always is. >> What might go wrong, if I continue to 'startx' >> with 'xorg-server' merged with 'suid -elogind' >> & without the '.xinitrc' line show above in the Wiki ? > For the majority of users -- those that use a graphics driver > with kernel modesetting support -- , X only needs root access > for a small set of things : accessing the DRM device node, > accessing the input device nodes and some stuff around VTs. > The rest of the time, X doesn't need root access. > With elogind, those bits are handled in a small daemon > and X no longer needs to run as root. Most people find that valuable, > especially with the knowledge that there have been > a number of security vulnerabilities that would allow arbitrary code > execution in the xserver over the years [1]. The latest of those was announced in 2018 & all of them seem to involve privilege escalation by local users ; those marked 'remote' all seem to be via off-site logins. There doesn't appear ever to have been a genuine remote threat, so single-user systems have never been threatened by xorg-server as root. > [1] > https://www.cvedetails.com/vulnerability-list/vendor_id-88/product_id-8600/X.org-Xorg-server.html So i ask again : Why is running 'xorg-server' as root "heavily discouraged" ? There was a similar issue a few years ago, when the game Nethack was threatened with removal from Gentoo due to a security problem which affected only multi-user systems. Is there any difference in this case of xorg-server ? -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatcadotinterdotnet
Re: [gentoo-dev] Re: News item: xorg-server dropping default suid
On Sun, Jun 21, 2020 at 4:53 PM Philip Webb wrote: > > 200621 Piotr Karbowski wrote: > > Title: xorg-server dropping default suid > ... > > The Gentoo X11 Team is announcing that starting with 15th of July, > > the x11-base/xorg-server will no longer default to suid > > and will default to using logind interface instead. This change > > makes xorg-server run as regular user rather than root by default, > > however those who do not have any logind interface provider > > -- either systemd or elogind -- will need to enable either > > to make it possible to run X session as unprivileged user. > > No action is required from systemd and desktop profile users, > > since systemd provides logind interface > > and desktop profile already enables 'elogind' USE flag globally. > > Rest of the non-systemd users is required to globally enable > > 'elogind' USE flag and apply it by 'emerge --newuse @world', > > after which, re-login is required so that PAM can allocate seat. > > One can confirm that a seat has been assigned upon login by running: > > $ loginctl user-status > > Those who for whatever reason want to preserve current state, > > while heavily discouraged, > > can still use x11-base/xorg-server with 'suid -elogind'. > > Gentoo Wiki says : > > elogind is the systemd project's logind, extracted to a standalone package. > It's designed for users who prefer a non-systemd init system, > but still want to use popular software such as KDE/Wayland or GNOME > that otherwise hard-depends on systemd. > > startx integration : To have an elogind session created > when using startx to start the X server (instead of a display manager), > add the following to the user's ~/.xinitrc file : FILE ~/.xinitrc >exec dbus-launch --exit-with-session > WINDOW_MANAGER in the above example needs to be replaced > by a window manager or a single application. > > I want to use 'startx' to start X , because I don't want to be trapped > if some problem arises with X or KDE or the login manager > & I need to change config files or remerge pkgs (etc) to rescue myself. > With 'startx' I can do all that work from raw TTYs with no problems, > as I am not forced to go into an X session if I don't want to. Thank you for actually participating in the discussion, unlike the last thread about this topic. > I don't want to use 'systemd', as I want to run a traditional UNIX version > of Linux + KDE (or Fluxbox) for a simple single-user desktop system. > > Why is running 'xorg-server' as root "heavily discouraged" ? > -- I've been doing that with Gentoo for > 16 yr without any problems. > AFAIK there are no problems re exploits via I/net browsers, > which are started by my user as all such user software always is. > What might go wrong, if I continue to 'startx' > with 'xorg-server' merged with 'suid -elogind' > & without the '.xinitrc' line show above in the Wiki ? For the majority of users (those that use a graphics driver with kernel modesetting support), X only needs root access for a small set of things: accessing the DRM device node, accessing the input device nodes, and some stuff around VTs. The rest of the time, X doesn't need root access but still must run as root for those cases I mention. With elogind, those bits are handled in a small daemon, and X no longer needs to run as root. Most people find that to be valuable, especially with the knowledge that there have been a number of security vulnerabilities found that would allow arbitrary code execution in the xserver over the years [1]. Our current default of USE=suid installs /usr/bin/Xorg with the setuid bit set, allowing it to be run *as root* by any user. This enables non-root users to execute startx, for example. I appreciate that Gentoo users are a diverse bunch, to say the least. This news item is about *defaults*. I'm happy to explain the value of the new default to people who are genuinely curious but I have no interest in trying to convince you or anyone else of anything. You're free to keep the status quo with a single line in /etc/portage/package.use. The people building and maintaining the distro think that the new defaults are better defaults for the vast majority of users, but again they're just defaults. [1] https://www.cvedetails.com/vulnerability-list/vendor_id-88/product_id-8600/X.org-Xorg-server.html
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2020-06-21 23:59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2020-06-21 23:59 UTC. Removals: app-cdr/sync2cd 20200618-00:51 bman b295ad0c99a app-i18n/atokx3 20200616-12:49 asturm bb04fe44a8e app-shells/rssh 20200620-04:46 bman a710a919055 app-text/getxbook20200618-00:51 bman b295ad0c99a dev-python/assets20200618-00:51 bman b295ad0c99a dev-python/bokeh 20200620-04:52 bman a8823e4da11 dev-python/bz2file 20200618-00:51 bman b295ad0c99a dev-python/flexx 20200620-04:52 bman a8823e4da11 dev-python/gconf-python 20200621-23:09 asturm 8cec92324ae dev-python/gnome-python-base 20200621-23:09 asturm 7e4b739eda6 dev-python/jaxml 20200618-00:51 bman b295ad0c99a dev-python/kid 20200618-00:51 bman b295ad0c99a dev-python/pygtksourceview 20200621-23:08 asturm c037972f080 dev-python/python-urljr 20200618-00:51 bman b295ad0c99a dev-python/restkit 20200620-04:48 bman 157b2f4a82f dev-python/selectors34 20200618-00:51 bman b295ad0c99a dev-python/stomper 20200618-00:51 bman b295ad0c99a dev-python/txtorcon 20200620-04:50 bman bb163772165 dev-python/YURL 20200618-00:51 bman b295ad0c99a dev-tex/revtex 20200620-04:49 bman e9566407501 net-analyzer/ripe-atlas-tools20200620-04:55 bman 141428dfb12 net-libs/ripe-atlas-sagan20200620-04:55 bman 141428dfb12 net-proxy/mitmproxy 20200620-04:54 bman cafca86e0ff sci-chemistry/nmrdepaker 20200618-11:15 asturm c12caa121cb www-client/ripe-atlas-cousteau 20200620-04:55 bman 141428dfb12 Additions: acct-group/fvwm-crystal 20200610-00:42 bman 26f7df4dfbd app-misc/asciicast-tools 20200617-23:59 chutzpah 60e97ab40bf app-text/foliate 20200615-16:34 grozin adc5e44f43a dev-python/requests-unixsocket 20200621-09:45 mgorny cc81527c2dd dev-python/text-unidecode20200618-20:34 mgorny abb41af9d2a dev-ruby/kramdown-parser-gfm 20200618-18:26 robbat2 8b7b6e78f48 dev-ruby/kramdown-syntax-coderay 20200619-07:48 graaff f0372fd601f dev-ruby/terminal-table 20200619-05:34 graaff b1820f5ad86 dev-ruby/unicode-display_width 20200619-05:31 graaff 6d2655b62eb dev-util/gitlab-ci-linter20200619-18:21 williamh 23c20f353ec net-misc/oidc-agent 20200619-17:12 marecki f1f6e093d99 net-proxy/mitmproxy 20200620-17:41 bman ea1bca05f2c sys-auth/AusweisApp2 20200523-16:22 conikost 3664d1690fe -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: dev-python/gnome-python-base,removed,asturm,20200621-23:09,7e4b739eda6 dev-python/gconf-python,removed,asturm,20200621-23:09,8cec92324ae dev-python/pygtksourceview,removed,asturm,20200621-23:08,c037972f080 net-analyzer/ripe-atlas-tools,removed,bman,20200620-04:55,141428dfb12 net-libs/ripe-atlas-sagan,removed,bman,20200620-04:55,141428dfb12 www-client/ripe-atlas-cousteau,removed,bman,20200620-04:55,141428dfb12 net-proxy/mitmproxy,removed,bman,20200620-04:54,cafca86e0ff dev-python/bokeh,removed,bman,20200620-04:52,a8823e4da11 dev-python/flexx,removed,bman,20200620-04:52,a8823e4da11 dev-python/txtorcon,removed,bman,20200620-04:50,bb163772165 dev-tex/revtex,removed,bman,20200620-04:49,e9566407501 dev-python/restkit,removed,bman,20200620-04:48,157b2f4a82f app-shells/rssh,removed,bman,20200620-04:46,a710a919055 sci-chemistry/nmrdepaker,removed,asturm,20200618-11:15,c12caa121cb app-cdr/sync2cd,removed,bman,20200618-00:51,b295ad0c99a app-text/getxbook,removed,bman,20200618-00:51,b295ad0c99a dev-python/YURL,removed,bman,20200618-00:51,b295ad0c99a dev-python/assets,removed,bman,20200618-00:51,b295ad0c99a dev-python/bz2file,removed,bman,20200618-00:51,b295ad0c99a dev-python/jaxml,removed,bman,20200618-00:51,b295ad0c99a dev-python/kid,removed,bman,20200618-00:51,b295ad0c99a dev-python/python-urljr,removed,bman,20200618-00:51,b295ad0c99a dev-python/selectors34,removed,bman,20200618-00:51,b295ad0c99a dev-python/stomper,removed,bman,20200618-00:51,b295ad0c99a app-i18n/atokx3,removed,asturm,20200616-12:49,bb04fe44a8e Added Packages: dev-python/requests-unixsocket,added,mgorny,20200621-09:45,cc81527c2dd net-proxy/mitmproxy,added,bman,20200620-17:41,ea1bca05f2c sys-auth/AusweisApp2,added,conikost,20200523-16:22,3664d1690fe dev-util/gitlab-ci-linter,added,williamh,20200619-18:21,23c20f353ec net-misc/oidc-agent,added,marecki,20200619-17:12,f1f6e093d99 dev-ruby/kramdown-syntax-coderay,added,graaff,20200619-07:48,f0372fd601f dev-ruby/terminal-table,added,graaff,20200619-05:34,b1820f5ad86 dev-ruby/unicode-display_width,added,graaff,20200619-05
Re: [gentoo-dev] Re: News item: xorg-server dropping default suid
200621 Piotr Karbowski wrote: > Title: xorg-server dropping default suid ... > The Gentoo X11 Team is announcing that starting with 15th of July, > the x11-base/xorg-server will no longer default to suid > and will default to using logind interface instead. This change > makes xorg-server run as regular user rather than root by default, > however those who do not have any logind interface provider > -- either systemd or elogind -- will need to enable either > to make it possible to run X session as unprivileged user. > No action is required from systemd and desktop profile users, > since systemd provides logind interface > and desktop profile already enables 'elogind' USE flag globally. > Rest of the non-systemd users is required to globally enable > 'elogind' USE flag and apply it by 'emerge --newuse @world', > after which, re-login is required so that PAM can allocate seat. > One can confirm that a seat has been assigned upon login by running: > $ loginctl user-status > Those who for whatever reason want to preserve current state, > while heavily discouraged, > can still use x11-base/xorg-server with 'suid -elogind'. Gentoo Wiki says : elogind is the systemd project's logind, extracted to a standalone package. It's designed for users who prefer a non-systemd init system, but still want to use popular software such as KDE/Wayland or GNOME that otherwise hard-depends on systemd. startx integration : To have an elogind session created when using startx to start the X server (instead of a display manager), add the following to the user's ~/.xinitrc file : FILE ~/.xinitrc exec dbus-launch --exit-with-session WINDOW_MANAGER in the above example needs to be replaced by a window manager or a single application. I want to use 'startx' to start X , because I don't want to be trapped if some problem arises with X or KDE or the login manager & I need to change config files or remerge pkgs (etc) to rescue myself. With 'startx' I can do all that work from raw TTYs with no problems, as I am not forced to go into an X session if I don't want to. I don't want to use 'systemd', as I want to run a traditional UNIX version of Linux + KDE (or Fluxbox) for a simple single-user desktop system. Why is running 'xorg-server' as root "heavily discouraged" ? -- I've been doing that with Gentoo for > 16 yr without any problems. AFAIK there are no problems re exploits via I/net browsers, which are started by my user as all such user software always is. What might go wrong, if I continue to 'startx' with 'xorg-server' merged with 'suid -elogind' & without the '.xinitrc' line show above in the Wiki ? Are there any other Gentoo users who have the same preferences as me ? -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatcadotinterdotnet
Re: [gentoo-dev] Re: Add commit to pull request
* Toralf Förster: > On 6/21/20 6:48 PM, Samuel Bernardo wrote: > >> Is it possible to add the commit to that pull request or I need to >> open a new pull request? > > yes Answering a colloquial "A or B" as a logical disjunction "A ∨ B"... Now that's just teasing. :-) -Ralph
Re: [gentoo-dev] Re: News item: xorg-server dropping default suid
On Sun, 2020-06-21 at 22:09 +0200, Piotr Karbowski wrote: > Hi, > > Re-sending news item inline. > > ### > > Title: xorg-server dropping default suid > Author: Piotr Karbowski > Posted: 2020-06-22 > Revision: 1 > News-Item-Format: 2.0 > Display-If-Installed: x11-base/xorg-server > > The Gentoo X11 Team is announcing that starting with 15th of July, > the x11-base/xorg-server will no longer default to suid and will default > to using logind interface instead. This change makes xorg-server run as > regular user rather than root by default, however, those who do not have > any logind interface provider (either systemd or elogind) will need to > enable either to make it possible to run X session as unprivileged user. No offense but it sounds a little chaotic to me. How about something like: Starting 2020-07-15 [use ISO dates, please], x11-base/xorg-server will default to using logind interface instead of suid by default. It will result in ... [what? better security?] through running the server as a regular user instead of root. However, this will require our users to use a logind provider such as elogind or systemd. > No action is required from systemd and desktop profile users, since > systemd provides logind interface, and desktop profile already enables > 'elogind' USE flag globally. > > Rest of the non-systemd users is required to globally enable 'elogind' The remaining users are ... 'elogind' [or 'systemd'?] > USE flag and apply it by 'emerge --newuse @world' Cut sentence here. > , after which, re-login > is required so that PAM can allocate seat. Afterwards, ... > > One can confirm that a seat has been assigned upon login by running: > > $ loginctl user-status > > Those who for whatever reason want to preserve current state, while > heavily discourage, can still use x11-base/xorg-server with 'suid -elogind'. 'whatever reason' doesn't sound professional. How about: Users who do not wish to use logind interface can manually reenable 'suid' flag in order to preserve the previous behavior. However, please note that this is heavily discouraged... [maybe explain why? also, are we going to eventually remove it?] -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: News item: xorg-server dropping default suid
Hi, Re-sending news item inline. ### Title: xorg-server dropping default suid Author: Piotr Karbowski Posted: 2020-06-22 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: x11-base/xorg-server The Gentoo X11 Team is announcing that starting with 15th of July, the x11-base/xorg-server will no longer default to suid and will default to using logind interface instead. This change makes xorg-server run as regular user rather than root by default, however, those who do not have any logind interface provider (either systemd or elogind) will need to enable either to make it possible to run X session as unprivileged user. No action is required from systemd and desktop profile users, since systemd provides logind interface, and desktop profile already enables 'elogind' USE flag globally. Rest of the non-systemd users is required to globally enable 'elogind' USE flag and apply it by 'emerge --newuse @world', after which, re-login is required so that PAM can allocate seat. One can confirm that a seat has been assigned upon login by running: $ loginctl user-status Those who for whatever reason want to preserve current state, while heavily discourage, can still use x11-base/xorg-server with 'suid -elogind'. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: News item: xorg-server dropping default suid
On Sunday, 21 June 2020 21:27:02 CEST Joonas Niilola wrote: > What's the current trend of attaching news items? It > makes hard to point out enhancements. Indeed, I didn't even look at the previous mail that was sent like that. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Add commit to pull request
Hi Samuel No you don't have to file a new PR. Basically, you have to: * commit your code against the branch. At that point, there are two commits (or more if you commit multiple times) in your branch, or PR if we talk in GH jargon. * squash that commit into the previous commit so as to get a single commit. * force push against said branch: git push -f origin your-awesome-pr. That's about it. This article sums up the process pretty well: https://www.devroom.io/2011/07/05/git-squash-your-latests-commits-into-one/ Cheers, Sunday 21 Jun 2020 17:48:14, Samuel Bernardo wrote : > Hi, > > I need to add a commit to a gentoo pull request that I had opened before. > > https://github.com/samuelbernardo/gentoo > > Is it possible to add the commit to that pull request or I need to open > a new pull request? > > I already try to get help in gentoo-dev channel but I haven't voice there... > > Thanks > >
[gentoo-dev] Re: News item: xorg-server dropping default suid
Hey, It has some typos. What's the current trend of attaching news items? It makes hard to point out enhancements. -- juippis On 6/21/20 10:22 PM, Piotr Karbowski wrote: > Hi, > > Please find news item attached. > > -- Piotr. signature.asc Description: OpenPGP digital signature
[gentoo-dev] News item: xorg-server dropping default suid
Hi, Please find news item attached. -- Piotr. Title: xorg-server dropping default suid Author: Piotr Karbowski Posted: 2020-06-22 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: x11-base/xorg-server The Gentoo X11 Team is announcing that starting with 15th of July, the x11-base/xorg-server will no longer default to suid and will default to using logind interface instead. This change makes xorg-server run as regular user rather than root by default, however, those who do not have any logind interface provider (either systemd or elogind) will need to enable either to make it possible to run X session as unprivileged user. No action is required from systemd and desktop profile users, since systemd provides logind interface, and desktop profile already enables 'elogind' USE flag globally. Rest of the non-systemd users is required to globally enable 'elogind' USE flag and apply it by 'emerge --newuse @world', after which, re-login is required so that PAM can allocate seat. One can confirm that a seat has been assigned upon login by running: $ loginctl user-status Those who for whatever reason want to preserve current state, while heavily discourage, can still use x11-base/xorg-server with 'suid -elogind'. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Add commit to pull request
On 6/21/20 6:49 PM, Toralf Förster wrote: > On 6/21/20 6:48 PM, Samuel Bernardo wrote: >> Is it possible to add the commit to that pull request or I need to open >> a new pull request? > yes > , you can add additional material to the same commit. It will be automatically handled by GitHub (and GitLab does simialr too FWIW) -- Toralf PGP 23217DA7 9B888F45 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Add commit to pull request
On 6/21/20 6:48 PM, Samuel Bernardo wrote: > Is it possible to add the commit to that pull request or I need to open > a new pull request? yes > I already try to get help in gentoo-dev channel but I haven't voice there... ask in #git :-) -- Toralf PGP 23217DA7 9B888F45 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Add commit to pull request
Hi, I need to add a commit to a gentoo pull request that I had opened before. https://github.com/samuelbernardo/gentoo Is it possible to add the commit to that pull request or I need to open a new pull request? I already try to get help in gentoo-dev channel but I haven't voice there... Thanks signature.asc Description: OpenPGP digital signature
[gentoo-dev] [PMS] [PATCH v2] Correct the definition of ESYSROOT as EPREFIX isn't always applicable
Coming back to this old thread (from July 2019). After some discussion
in #gentoo-pms today, here is an updated version of the patch.
Cross-posting to gentoo-dev and CCing prefix again, to make sure that
everyone is on the same page.
Ulrich
From 712772b7ef5543693147d8f96c03189e810a6ee8 Mon Sep 17 00:00:00 2001
From: James Le Cuirot
Date: Sun, 28 Jul 2019 22:37:35 +0100
Subject: [PATCH] Correct the definition of ESYSROOT as EPREFIX isn't always
applicable
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
It was originally envisaged (but not stated in PMS) that SYSROOT would
only ever need to equal / or ROOT as a distinct SYSROOT would have no
benefit. A check was added to Portage to ensure this held. Myself, the
ChromiumOS team, and others have since been caught out by this check
when trying to bootstrap brand new systems from scratch. You cannot
bootstrap with no headers at all! The check will therefore be adjusted
to merely ensure that SYSROOT is / when ROOT is /.
There were differing assumptions about how prefixes applied to the
above. EPREFIX is traditionally something the user sets so some
thought that it would be applied to SYSROOT, regardless of the
latter's value. In order to honor the rule about there being no
distinct SYSROOT, this would mean that if SYSROOT is / then EPREFIX
would have to match BROOT. Despite that limitation, ESYSROOT was
written into PMS with a fixed value of ${SYSROOT}${EPREFIX}. Being
somewhat unfamiliar with prefix at the time, I didn't realise that
this view didn't align with what I'd had in mind and it was only when
I came to need a distinct SYSROOT that I realised there was a problem.
crossdev toolchains are installed to ${EPREFIX}/usr/${CHOST} but have
no further prefix appended and packages subsequently installed with
cross-emerge are placed in this location by setting ROOT. Bug #642604
recently revealed that the build system's prefix was being erroneously
duplicated on the end but I have now fixed this.
What if we want to bootstrap a brand new prefixed system using the
crossdev system as SYSROOT? This is the distinct SYSROOT case. The
problem is that there is no distinct variable for SYSROOT's prefix
and, as already stated, ESYSROOT is always ${SYSROOT}${EPREFIX}. We
therefore cannot do it! If the crossdev prefix is blank then ROOT's
must be blank too.
I also never intended to have the aforementioned limitation where
EPREFIX must match BROOT when SYSROOT is /. These are both entirely
artificial restrictions.
So how should it work instead? We originally intended for SYSROOT to
equal either / or ROOT so I imagined the prefix would automatically be
adjusted to match the prefix applicable at the matching location,
namely BROOT or EPREFIX. This is obviously more flexible than forcing
it to match EPREFIX.
What about the distinct SYSROOT case? With no distinct variable, we
have no way to explicitly set a prefix but this is likely only needed
when bootstrapping against crossdev systems, which are unprefixed by
nature. We therefore simply assume that the prefix is blank in this
case.
What about the cross-prefix case? Here, SYSROOT matches both / and
ROOT so which prefix do we choose? The bootstrap-prefix.sh script sets
flags to build against the target prefix so EPREFIX is used in this
case. This happens to fit the current definition of ESYSROOT anyway.
Legitimate concerns have been raised about building for a system with
a different prefix to the one you're building against. The only
binaries that leak from SYSROOT to ROOT are static libraries. Headers
from SYSROOT will obviously also influence how ROOT's binaries are
built. It is entirely possible that SYSROOT's prefix may leak through
a header but grepping /usr/include on my own main system reveals only
a few paths from a small handful of packages. pkg-config files
invariably include paths but these are almost always used at build
time, not runtime. A differing prefix would likely only occur in cases
involving core packages like the libc and kernel headers anyway. Also
consider that we have never prevented this from happening in the
past. It has always been possible to do "EPREFIX=/foo emerge bar" from
some system with a different prefix or no prefix at all. All we're
doing here is including the prefix (if any) in the ESYSROOT variable.
Should this warrant a new EAPI? I don't think so. All existing usage
of ESYSROOT that I have seen still fits with this new definition and
most of that usage has come from me. We're not even changing what the
variable is used for, just loosening the constraints around what it
can be set to.
If you have doubts about whether this makes sense or actually works in
practise, I have experimented with a prefixed system using all the
different combinations I could think of, including cross-compiling,
and it all worked as expected. Keep in mind that ESYSROOT is not magic
and currently isn't used very much. As such, neither the toolchain nor
