| 1 |
On Tue, Jul 04, 2006 at 11:04:07PM -0700, Zac Medico wrote: |
| 2 |
> Hi everyone, |
| 3 |
> |
| 4 |
> Has anyone noticed that java-pkg-2.eclass makes it difficult to use |
| 5 |
> pre/post phase hooks in /etc/portage/bashrc? |
| 6 |
|
| 7 |
Yep, they were greenlighted _only_ because it's a workaround for bug |
| 8 |
#56408, bad environment handling by portage. |
| 9 |
|
| 10 |
> Wouldn't it be wise to |
| 11 |
> provide a function for registering these types of things, so that |
| 12 |
> more than one can be registered without stomping out others that |
| 13 |
> were registered before? |
| 14 |
|
| 15 |
No. Pre/post are user phase hooks only- their only real reason for |
| 16 |
existance is because with proper environment handling (namely true |
| 17 |
store/restoring of the env without having to try recreating it), it's |
| 18 |
the only way to preserve bashrc functionality. |
| 19 |
|
| 20 |
Strictly user level hooks, mandated that way to prevent the ebuild |
| 21 |
phases from going 2x what's there. If (as you're suggesting) a |
| 22 |
registration func were added, ebuild devs would also run into issues |
| 23 |
of registration order, and needing to yank a registered func from one |
| 24 |
of the hooks... further mess iow. |
| 25 |
|
| 26 |
|
| 27 |
Reiterating, for java pkgs to work properly, the environment _needs_ |
| 28 |
to be preserved and not stomped per phase change- portages env |
| 29 |
handling is broke, java usage of it is a stop gap measure rather then |
| 30 |
having to rewrite all java ebuilds to include per phase env restoring |
| 31 |
working around portage. |
| 32 |
|
| 33 |
pre/post is, and should remain strictly user level except when |
| 34 |
greenlighted by QA as a bandaid (as this was)- shouldn't be expanded |
| 35 |
any further (especially since it was an EAPI change that wasn't |
| 36 |
versioned since it occured prior to EAPI existing). |
| 37 |
|
| 38 |
~harring |
Archives