A forums script cfg-update mantains a database of MD5 sums of config files. This database needs to be updated before emerge installs new config files. Currently users of this are forced to alias emerge in /etc/profile, or to make their own wrapper script for emerge in /usr/bin.
It should be easy (four lines total?) to introduce two new files in /etc/portage that would be executed before and after every run of portage (I would suggest preemerge.sh and postemerge.sh). I can imagine a number of other possible uses for this. For instance one might want to automatically push tarballs of newly built software to a server or back up critical directories or take down/restart services on the computer.
Any major concerns with this idea?
Steps to Reproduce:
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)