Summary: | pre_sync script | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Alexander Sulfrian <alexander> |
Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED TEST-REQUEST | ||
Severity: | normal | CC: | alex_y_xu |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Alexander Sulfrian
2008-11-30 02:38:54 UTC
(In reply to comment #0) > btw. why is it handled different: during normal emerge the different stages > execute bashrc with a enviroment variable and after emerge --sync the > /etc/portage/bin/post_sync is executet. Why isn't emerge --sync also calling > the bashrc with EBUILD_PHASE set to post_sync and add maybe pre_sync. Because syncing is not an ebuild phase, it's a conceptually completely different thing. There is a lot more to ebuild phase execution than just setting a single variable, trying to force sync into the same framework would be a real mess. (In reply to comment #1) > [...] trying to force sync into the same framework would > be a real mess. Ah ok. But is it possible to add something similar to the syncprocess? Like pre_sync? for syncing overlays, if you insist that it should be done in portage (I say wrapper script is better), there seems to be no reason why postsync.d cannot be used. |