| Summary: | automatically run user specified programs before or after emerge | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | David Escott <david.escott> |
| Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
| Status: | VERIFIED LATER | ||
| Severity: | enhancement | CC: | kyron, xentric |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
David Escott
2004-11-10 13:11:29 UTC
I'm the author of cfg-update and I think that David has brought up an excellent solution that would serve other purposes as well. If this functionality is added to portage I can modify cfg-update so users don't have to alias the emerge command anymore. It's a clean and simple solution! I am a long time user of cfg-update and also favour this solution over the current aliasing method. Additionally what could be done would be to set what pre/post files were to be run in the make.conf, having them defaulted to preemerge/postemerge.sh in /etc/portage as suggested and overriden by variables set in the make.conf. I can see many advantages for this. Reading the forums I have seen many people alias a variety of tasks to emerge, such as source /etc/profile, env-update, ldconfig and many more. This would be a simple and elegant solution to cover all of these needs. Though this suggestion and bug #32728 to be entirely valid, I am starting to believe that there is no motion to get cfg-update fully funtionnal with portage for two reasons: 1- Portage people don't want to "patch" misfuntionnalities of portage 2- (this is whishful thinking) Portage people are already trying to integrate the cfg-update functionnalities/flexibility into portage... Now I can only hope to get some confirmation, le ye be negative or positive, about my assumptions... Any devs out there?! (I'm "just" a user...) I've heard arguments like this a lot. "Don't put this or that feature in portage" (features that would help working with a gentoo system tremendously), "because this would be just a hack and this functionality will be in portage one day anyway". Last time developers argued this way it was about a very similar issue, namely my wish to enable emerge to run dispatch-conf right after finishing. Why not make life easier for many people? Would this functionality hurt portage in any way? Later, when the functionality is directly in portage, people will simply be able to comment out the commands in pre- and postemerge.sh. I believe hooks are planned for specific stages of the emerge process ( pre_inst, post_inst, etc...) however these will probably come much later. There is also something I think a lot of people miss. There are not a mess of portage developers and portage has many feature requests. It's not like you can just request something and it magically gets made because they work on whatever you tell them to. Your best bet to getting this implemented is either to A. write patches yourself, or B. Convince them it's impossible to live without. And here B. is pretty much already done, it's in the plans, but there are a lot more important features that need to be done first ;) </rant> Putting a hold on feature requests for portage as they are drowning out the bugs. Most of these features should be available in the next major version of portage. But for the time being, they are just drowning out the major bugs and delaying the next version's progress. Any bugs that contain patches and any bugs for etc-update or dispatch-conf can be reopened. Sorry, I'm just not good enough with bugzilla. ;) Consider this closed as WONTFIX. alias or wrapper script is trivial to write if you want it, and not everything can be called properly from within portage (especially a postemerge hook would have a number of restrictions due to atexit stuff) |
