Handbook Talk:AMD64/Portage/Advanced

From Gentoo Wiki
Jump to:navigation Jump to:search
Note
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

Talk status
This discussion is done as of 2024-05-11.

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)
For my personal understanding the handbook should be kept free of such kind of helpful notes which are not really needed for getting a first Gentoo system going. I think it's better homed in a non-handbook wiki article.
--Vaukai (talk) 08:34, 25 August 2022 (UTC)
Fixed in Special:Diff/1271693/1298195, thanks!
--csfore (talk) 20:24, 11 May 2024 (UTC)

Conflicting bashrc information

Talk status
This discussion is still ongoing as of 2024-08-09.

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):

FILE /etc/portage/bashrc
function post_pkg_postinst() {
        echo "This is a test."
}

As described in the handbook (does nothing):

FILE /etc/portage/bashrc
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 of echo work?
-- Flexibeast (talk) 04:30, 3 October 2024 (UTC)
einfo did not work, but eerror 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 not einfo?
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, as einfo does - cf. /usr/lib/gentoo/functions.sh. What happens if you use echo 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 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_ and post_ instead of using the environment variables EBUILD_PHASE and EBUILD_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

Talk status
This discussion is done as of 2024-10-18.

"Using /etc/portage/env" section

Proposed changes - Please make edits here until a final revision is agreed upon.

Using /etc/portage/env
Proposed changes - Please make edits here until a final revision is agreed upon.

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.

Proposed changes - Please make edits here until a final revision is agreed upon.

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

Proposed changes - Please make edits here until a final revision is agreed upon.

These types of hooks are run after updating (also referred to as 'syncing') the Gentoo ebuild repository.
Proposed changes - Please make edits here until a final revision is agreed upon.

If a symlink was created which pointed to eix, but was not called eix-update, it would not run correctly.

"Overriding profile settings" section

Proposed changes - Please make edits here until a final revision is agreed upon.

These profiles define specific settings and inherit settings from other profiles (through their parent files).
Proposed changes - Please make edits here until a final revision is agreed upon.

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.
Proposed changes - Please make edits here until a final revision is agreed upon.

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)