Please consider adding epatch_user support to sys-apps/portage. It looks like it could be achieved by sdding "epatch_user" to the end of the src_prepare function. epatch_user support would allow me (and other) to apply custom patches. In my setup I am using http-replicator like recommended in the wiki to cache distfiles for my network. To do that, I set the "http_proxy" environment variable in make.conf. Because my clients also uses binpkgs, portage would use the same proxy to download the binpkgs which would fill up the cache with unwanted files (the binhost is already in the same network, no need to cache these files). So I wrote a simple patch which would unset http_proxy if defined in BinpkgFetcher.py which will solve my problem. Currently I have to fork the portage ebuild to apply my patch. With euser_patch support, I wouldn't have to do that. Thanks. Reproducible: Always
Actually, just adding "epatch_user" is not enough, because the last code block in the current src_prepare function changes the CWD so we have to change it back to $S before we call epatch_user: --- /usr/portage/sys-apps/portage/portage-2.2.7.ebuild 2013-11-04 01:01:34.000000000 +0100 +++ /usr/local/portage/sys-apps/portage/portage-2.2.7.ebuild 2013-11-14 19:54:44.575861288 +0100 @@ -312,6 +312,9 @@ eerror "Please notify the arch maintainer about this issue. Using generic." eerror "" fi + + cd "${S}" || die + epatch_user } src_compile() { Thanks :)
Created attachment 371688 [details, diff] portage_ebuild_fix.patch actually switch back from ${S}/cnf back to ${S} is enough to get patches works again. Please fix. Thank you David
(In reply to David Heidelberger (okias) from comment #2) portage-2.2.8-r1.ebuild does not call epatch_user, so changing to ${S} accomplishes nothing. If you are using a bashrc hook to hack in a call to epatch_user, just add cd ${S} to that.
We had a discussion on IRC and basically decided we were not willing to support this use case. The portage-9999 ebuild has this functionality and we would prefer to limit that to people who are actively developing portage (as opposed to users.) -A
Thank you, I didn't realized I used bashrc. I added to wiki page about patches cd ${S}, but anyway, shouldn't be bash in this directory automatically, when using different function? (src_prepare switch dir, post_src_prepare should use default ${S}, right?) (In reply to Mike Gilbert from comment #3) > (In reply to David Heidelberger (okias) from comment #2) > > portage-2.2.8-r1.ebuild does not call epatch_user, so changing to ${S} > accomplishes nothing. > > If you are using a bashrc hook to hack in a call to epatch_user, just add cd > ${S} to that.
*** Bug 515248 has been marked as a duplicate of this bug. ***
(In reply to Alec Warner from comment #4) > We had a discussion on IRC and basically decided we were not willing to > support this use case. The portage-9999 ebuild has this functionality and we > would prefer to limit that to people who are actively developing portage (as > opposed to users.) > > -A Sorry for reopening this discussion, but I really don't understand your decision. This shouldn't be about "limiting" anything, it's just about making lifes easier. The unavailability of epatch_user just means I have to create an local copy of the ebuild or patch the life system (I did the latter). What would you loose by supporting epatch_user? If a user causes horrible breakage on his own accord, then it's his problem, not yours.
(In reply to Luis Ressel from comment #7) > (In reply to Alec Warner from comment #4) > > We had a discussion on IRC and basically decided we were not willing to > > support this use case. The portage-9999 ebuild has this functionality and we > > would prefer to limit that to people who are actively developing portage (as > > opposed to users.) > > > > -A > > Sorry for reopening this discussion, but I really don't understand your > decision. This shouldn't be about "limiting" anything, it's just about > making lifes easier. The unavailability of epatch_user just means I have to > create an local copy of the ebuild or patch the life system (I did the > latter). > > What would you loose by supporting epatch_user? If a user causes horrible > breakage on his own accord, then it's his problem, not yours. s/life/live/, I guess you know what I mean.
Please also note that I'm not doing anything weird with portage, I'm just testing a new portage feature introduced by blueness because he asked for it - but I don't want to switch to -9999 entirely. Shouldn't it be as easy as possible for users to help devs with testing something? (I'm only writing this to show that there are use cases which you might consider more "legitimate".)
(In reply to Luis Ressel from comment #7) > (In reply to Alec Warner from comment #4) > > We had a discussion on IRC and basically decided we were not willing to > > support this use case. The portage-9999 ebuild has this functionality and we > > would prefer to limit that to people who are actively developing portage (as > > opposed to users.) > > > > -A > > Sorry for reopening this discussion, but I really don't understand your > decision. This shouldn't be about "limiting" anything, it's just about > making lifes easier. The unavailability of epatch_user just means I have to > create an local copy of the ebuild or patch the life system (I did the > latter). > > What would you loose by supporting epatch_user? If a user causes horrible > breakage on his own accord, then it's his problem, not yours. What do we have to lose?? How about more time wasted by use for problems due to some unknown patch being applied. We already get way too many bugs assigned to dev-portage for problems that usually end up as a pkg/ebuild problem not due to portage. If a user puts their own custom ebuild for portage to allow them to patch it, that is easier to detect. Also why would we want to have lots of users making custom patches to portage and not submit them for possible inclusion in mainline portage. If there is truly a patch that does fix something, we want to know about it. Having patches floating around different users that do not know how to sort out the source of troubles it may ocause will not help anyone. The reason they are allowed for the 9999 ebuild, is that is git HEAD or close to it (depending on when it was emerged and the commits made), so it allows testing patches easier for possible bugs. And if a patch is going to be applied to portage, it is a far better chance that it will apply cleanly and not have other side effects because it was applied to a portage version some unknown number of commits earlier in the git patch tree.
