Handbook Talk:AMD64/Portage/Advanced
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using
~~~~
:
A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC) : A reply [[User:Sally|Sally]] 10:33, 12 November 2024 (UTC) :: Your reply ~~~~
Old epatch references
Section #Using_eapply_user needs update:
* epatch.eclass is deprecated, so should not be mentioned here * legacy (pre-EAPI 6) ebuilds, they all are gone.
--Vaukai (talk) 07:29, 25 August 2022 (UTC)
- I deliberately wrote the remark that way because I felt it was still worth mentioning how to handle older ebuilds in say, overlays. < EAPI 6 ebuilds still exist in the world. But if it's felt that it's too confusing, we can drop it entirely, I guess. --Sam (talk) 08:04, 25 August 2022 (UTC)
- Fixed in Special:Diff/1271693/1298195, thanks!
- --csfore (talk) 20:24, 11 May 2024 (UTC)
Conflicting bashrc information
In the section, "Example: Updating the file database", the code block uses the EBUILD_PHASE* variables. On the /etc/portage/bashrc wiki page, there is a note stating the following: "Do not rely on variables EBUILD_PHASE or EBUILD_PHASE_FUNC. Their value in global scope is not supposed to be the name of a phase; see bug #908552."
After trying both methods, with and without using the EBUILD_PHASE* variables, neither seem to work.
As described in the /etc/portage/bashrc wiki (does nothing):
function post_pkg_postinst() {
echo "This is a test."
}
As described in the handbook (does nothing):
if [ "$EBUILD_PHASE" == "postinst" ]; then
echo "This is a test."
fi
FlyingBullets (talk) 19:04, 9 August 2024 (UTC)
- That's odd; using
if [ "${EBUILD_PHASE}" == "postinst" ]
is certainly working for me, as per my "desktop notifications of emerge progress" setup. Does using e.g.einfo
instead ofecho
work? - -- Flexibeast (talk) 04:30, 3 October 2024 (UTC)
einfo
did not work, buteerror
did using both methods... strange. This seems to be two separate issues:- 1. There is still a conflict in the wiki pages.
- 2. Some Portage functionality is not working with /etc/portage/bashrc -- why does
eerror
work but noteinfo
?
- I haven't modified Portage's behavior besides the usual make.conf and package.*.
- FlyingBullets (talk) 17:15, 6 October 2024 (UTC)
- i would guess it's related to
eerror
writing to stderr rather than stdout, aseinfo
does - cf. /usr/lib/gentoo/functions.sh. What happens if you useecho
with a redirection of stdout to stderr, i.e.echo "This is a test." 1>&2
? And more generally, are you setting any SANDBOX_* variables anywhere, including in your make.conf?
- i would guess it's related to
- i don't really understand what's meant by that Note in the '/etc/portage/bashrc' page, even after reading the thread for the linked bug; i might add a comment on that bug asking if one of the relevant devs could clarify what that Note is trying to convey. Given the commit message in the most recent comment on that bug, i think it might be trying to say that the referenced variables shouldn't be relied upon within ebuilds, in contrast to their usage in a bashrc context, but i might be completely wrong.
- -- Flexibeast (talk) 21:31, 6 October 2024 (UTC)
- EBUILD_PHASE and EBUILD_PHASE_FUNC are only meaningful in phases (and of course this applies to phases in ebuilds). PMS says that their value in global scope must not be the name of a phase. Unfortunately, Portage doesn't follow that specification (bug #908552); I guess that's where the confusion arises from.
- Then again, it is not entirely clear in what context the /etc/portage/bashrc file is sourced. The portage(5) man page is silent about phases, so I'd consider using EBUILD_PHASE or EBUILD_PHASE_FUNC in bashrc an undocumented feature. --ulm (talk) 06:04, 7 October 2024 (UTC)
- Gotta love it when the developer says it's an "undocumented feature"! XD
- So... should Handbook:AMD64/Portage/Advanced be updated to reflect how it "should" be done in /etc/portage/bashrc? In other words, use hook functions with prefixes
pre_
andpost_
instead of using the environment variablesEBUILD_PHASE
andEBUILD_PHASE_FUNC
? - FlyingBullets (talk) 15:28, 7 October 2024 (UTC)
echo "This is a test." 1>&2
does nothing; I even ran emerge with--ignore-default-opts
.root #
grep -r SANDBOX_ /etc/
/etc/sandbox.d/15man-db:SANDBOX_PREDICT="/var/cache/man"
/etc/sandbox.d/37fontconfig:SANDBOX_PREDICT="/var/cache/fontconfig"
/etc/sandbox.d/00default:# Also note that SANDBOX_WORKDIR is a special variable that is just set if
/etc/sandbox.d/00default:SANDBOX_READ="/"
/etc/sandbox.d/00default:SANDBOX_WRITE="${SANDBOX_WORKDIR}"
/etc/sandbox.d/00default:SANDBOX_WRITE="/usr/tmp/conftest:/usr/lib/conftest:/usr/lib32/conftest:/usr/lib64/conftest:/usr/tmp/cf:/usr/lib/cf:/usr/lib32/cf:/usr/lib64/cf"
/etc/sandbox.d/00default:SANDBOX_PREDICT="${HOME}"
/etc/sandbox.d/10openssl:SANDBOX_PREDICT="/dev/crypto"
/etc/sandbox.conf:# SANDBOX_VERBOSE
/etc/sandbox.conf:#SANDBOX_VERBOSE="yes"
/etc/sandbox.conf:# SANDBOX_DEBUG
/etc/sandbox.conf:#SANDBOX_DEBUG="no"
/etc/sandbox.conf:# SANDBOX_METHOD
/etc/sandbox.conf:#SANDBOX_METHOD="any"
/etc/sandbox.conf:# SANDBOX_DENY - all access to respective paths are denied
/etc/sandbox.conf:# SANDBOX_READ - can read respective paths
/etc/sandbox.conf:# SANDBOX_WRITE - can write to respective paths
/etc/sandbox.conf:# SANDBOX_PREDICT - respective paths are not writable, but no access violation
/etc/sandbox.conf:SANDBOX_WRITE="/dev/fd:/proc/self/fd"
/etc/sandbox.conf:SANDBOX_WRITE="/dev/zero:/dev/null:/dev/full"
/etc/sandbox.conf:SANDBOX_WRITE="/dev/console:/dev/tty:/dev/vc/:/dev/pty:/dev/tts"
/etc/sandbox.conf:SANDBOX_WRITE="/dev/ptmx:/dev/pts/:/dev/shm"
/etc/sandbox.conf:SANDBOX_WRITE="/tmp/:/var/tmp/:/usr/tmp/"
/etc/sandbox.conf:SANDBOX_WRITE="${HOME}/.bash_history"
- FlyingBullets (talk) 15:28, 7 October 2024 (UTC)
Suggested changes
"Using /etc/portage/env" section
Using /etc/portage/env
To enable debugging for the media-video/mplayer package:
"Hooking into the emerge process" section
General suggestion: Capitalise 'Bash' when referring to the shell unless specifically referencing the bash command.
In this example, the /etc/portage/bashrc file will be used to call some file database applications to ensure their databases are up-to-date with the system.
"Executing tasks after ebuild repository syncs" section
These types of hooks are run after updating (also referred to as 'syncing') the Gentoo ebuild repository.
If a symlink was created which pointed to eix, but was not called eix-update, it would not run correctly.
"Overriding profile settings" section
These profiles define specific settings and inherit settings from other profiles (through their parent files).
By using /etc/portage/profile, system administrators can override profile settings such as packages (what packages are considered to be part of the @system set), force USE flags, and more.
which will cause Portage to heavily warn administrators in the event they attempt to unmerge it.
- Thanks! Fixed in Special:Diff/1315863/1316649
- --csfore (talk) 22:49, 18 October 2024 (UTC)