Summary: | virtual/awk-1 - /usr/lib/portage/python3.6/ebuild.sh: line 309: unset: IUSE: cannot unset: readonly variable | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | inactive <gentoo_eshoes> |
Component: | Current packages | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | gentoo_eshoes, mgorny |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | this is causing the issue: /etc/portage/bashrc |
Description
inactive
2020-02-20 13:00:19 UTC
I don't think that is a bug in virtual/awk. This looks like something you'd get via FEATURES=keeptemp or alike but I don't see it used here. Created attachment 614618 [details]
this is causing the issue: /etc/portage/bashrc
because source-ing epatch.class from /etc/portage/bashrc, which in turn sources estack.class and thus resulting in this very bug/issue.
I mean, eclass not class: /var/db/repos/gentoo/eclass/epatch.eclass /var/db/repos/gentoo/eclass/estack.eclass You're on your own with that bashrc code. (In reply to Mike Gilbert from comment #5) > You're on your own with that bashrc code. Right, of course. I just didn't realize it was the cause until then. Sorry for wasting people's time. From now on, I promise to wait at least 2 days (during which I try to find the causes) before opening any (new)bug reports, as a sign of respect for devs time:) Cheers! ok, so all I had to do to make it work with my bashrc (from above), was to just add the line "inherit eutils" in virtual/awk/awk-1.ebuild after the EAPI=5 line test with: # emerge --ask n --unmerge virtual/awk ; time emerge -v1 --ask n virtual/awk::localrepo The localrepo, for whoever stumbles upon this(including future me) was created as per [1] and [2] in order to make it more convenient to change/override ebuilds without modifying them in the rsync-ed repo directly. [1] https://wiki.gentoo.org/wiki/Handbook:AMD64/Portage/CustomTree#Defining_a_custom_repository [2] https://wiki.gentoo.org/wiki/Custom_repository#Creating_a_local_repository on second thought, just 'inherit epatch' is necessary! which eutils already does. (In reply to gentoo_eshoes from comment #7) > ok, so all I had to do to make it work with my bashrc (from above), was to > just add the line "inherit eutils" in virtual/awk/awk-1.ebuild after the > EAPI=5 line There's no valid reason for the virtual/awk ebuild to inherit any eclasses. You're right, that's just something for my bashrc to work(and I'm still trying to figure out why). Nothing for Gentoo devs to change! If I source/inherit epatch inside this 'if' (within /etc/portage/bashrc ofc): if [[ $EBUILD_PHASE == @(setup) ]]; then then it works without modifying virtual/awk-1 ebuild But if I try to source it inside this 'if': if [[ $EBUILD_PHASE == @(prepare|src_prepare) ]]; then or within these 3 functions(thus far tested): pre_pkg_setup() { post_pkg_setup() { pre_src_prepare() { then it fails as in OP. This seems a bit inconsistent because those pre/post_pkg_setup functions should be the same as that first 'if' mentioned: if [[ $EBUILD_PHASE == @(setup) ]]; then and yet, they act differently. oh well. You should not need to source or inherit any eclasses inside bashrc, and it's not considered a valid use case. Ebuilds using EAPI 6 and later have built-in support for user patches via the eapply_user function. For ebuilds using older EAPIs, you can send a pull request to add an epatch_user call to the ebuild. |