[gentoo-portage-dev] [PATCH] Enable cgroup, ipc-sandbox network-sandbox by default
All three features should be mature enough to be enabled by default.
CGroups provide better tracking for ebuild processes, while the two
sandboxes improve security through restricting IPC network access for
build-only phases.
All the features degrade gracefully when the relevant kernel features
are not available.
---
cnf/make.globals | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/cnf/make.globals b/cnf/make.globals
index dd99618..2d93e9d 100644
--- a/cnf/make.globals
+++ b/cnf/make.globals
@@ -50,9 +50,10 @@ RESUMECOMMAND_SSH=${FETCHCOMMAND_SSH}
FETCHCOMMAND_SFTP=bash -c \x=\\\${2#sftp://} ; host=\\\${x%%/*} ;
port=\\\${host##*:} ; host=\\\${host%:*} ; [[ \\\${host} = \\\${port} ]]
port=22 ; eval \\\declare -a ssh_opts=(\\\${3})\\\ ; exec sftp -P \\\${port}
\\${ssh_opts[@]}\\\ \\${host}:/\\\${x#*/}\\\ \\$1 sftp
\\${DISTDIR}/\${FILE}\ \\${URI}\ \\${PORTAGE_SSH_OPTS}\
# Default user options
-FEATURES=assume-digests binpkg-logs
+FEATURES=assume-digests binpkg-logs cgroup
config-protect-if-modified distlocks ebuild-locks
- fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned
+ fixlafiles ipc-sandbox merge-sync network-sandbox
+ news parallel-fetch preserve-libs protect-owned
sandbox sfperms strict unknown-features-warn unmerge-logs
unmerge-orphans userfetch userpriv usersandbox usersync
--
2.3.5
Re: [gentoo-portage-dev] Re: Dynamic USE dependencies
On Mon, Apr 6, 2015 at 8:02 AM, Martin Vaeth mar...@mvath.de wrote: My suggestion is something in between - less invasive (and, in particular, less time consuming) than your suggestion to recalculate the USE-settings with every emerge, but more automatic than the current state. Keep in mind that keeping track of past decisions made by portage does not require user-editable config files in /etc. It just requires a cache of some kind, much as we do with installed packages/etc. That said, portage still has to spend time basically re-validating the consistency of the entire system because we allow the use of overlays and other situations that don't guarantee that portage will have some kind of consistent pre-calculated depgraph handed to it. If we required all repositories to have some kind of pre-generated cache in them and ensured that this was always up-to-date and better controlled the kinds of dependency changes we made, then maybe there might be an opportunity to offload some of the work to the repository level instead of doing it on every Gentoo system. Still, unless we banned overlays I'm not sure how much even this would buy you, since you'd have many of these that need to be merged somehow. From Zac's email and other discussions in the past it seems like we're basically committed to doing all these calculations all the time anyway, so we shouldn't be too shy about taking advantage of them. -- Rich
[gentoo-portage-dev] Re: Dynamic USE dependencies
Rich Freeman ri...@gentoo.org wrote: On Sun, Apr 5, 2015 at 11:47 AM, Martin Vaeth mar...@mvath.de wrote: One suggestion around this problem would be to use different directories for these two types of use-flags, say package.use and package.use.needed. I still think we need a better long-term solution, but the workaround is simpler than that. I try to keep files in directories for package.keywords and package.use. One starts with a z and is a dumping ground for auto-whatever. So you use package.use/z instead of package.use.needed as in my suggestion. (In fact, I do currently a similar thing, only that I use a file named zzz_autounmask, because this is even later in the alphabet). I think it would be more transparent to the user if really a dedicated directory/file would be used and not some which by accident is the last in the alphabet. Anyway, this is a minor issue. The main problem is how to cleanup this directory/file (no matter how it is called). Currently, the only way to do this, is to remove this file and to hope that portage can recreate it. Unfortunately, quite often portage is not able to do this. The problem is at least NP hard, so probably any backtracking value just is too low. If portage would use the old values as a hint, how conflicts might possibly be resolved, perhaps this algorithm might be improved. However, I think a cleaner solution would be better... ++ My suggestion is something in between - less invasive (and, in particular, less time consuming) than your suggestion to recalculate the USE-settings with every emerge, but more automatic than the current state. With my suggestion the USE-settings have to be recalculated only if a special command is used (or - as currently - if resolving is not possible without changing USE-flags). Probably other approaches are possible, too.
