I think this is too minor to be a GLEP hence I'm putting it here. ABSTRACT Add functionality to emerge to trigger messages after 'emerge sync' has completed. The triggers for these messages and the messages themselves are user defined. MOTIVATION Very often I'm waiting for certain packages to go stable before I do something. For example I use gpg-agent which has now been masked. The functionality of gpg-agent is now in gnupg-1.9 and above (I'm told) but these packages are still marked unstable. I don't want the unstable branch of gnupg so I'm waiting for a late enough version of gnupg to go stable after which I'll dump gpg-agent and do whatever I need to do with gnupg to get a similar functionality. Another example: I need a relatively new kernel but I also use nvidia-kernel so I have to use the unstable branch of nvidia-kernel to keep compatability with the kernel. I don't like using unstable if I don't have to so I'm waiting for nvidia-kernel to go stable at a high enough version after which I'll switch to the stable packages. Because of this I have to monitor the situation with these packages and I'd really like the computer to do the monitoring for me. SPECIFICATION This is a change to the emerge script only and also requires the user to create a new file "package.warnme" under /etc/portage if, and only if, he/she wants to use these triggers. A patch file is provided against the emerge script from the currently stable portage package, 2.0.54-r2. Please note that this is a rough-and-ready effort to demonstrate this idea, I'm no expert in portage details nor in using python, any suggestions and improvements will be gratefully received. Triggers for the warning messages are put in /etc/portage/package.warnme and consist of one trigger per line, blank lines are allowed and lines beginning with # are ignored. Each line should be of the following format: Trigger condition<white space>arch<white space>Free text. examples: Trigger condition: >=app-crypt/gnupg-1.9 arch: x86 ~x86 An example file is attached with this report. RATIONALE I hope this is adequately explained under MOTIVATION, it can get quite onerous tracking multiple packages after each sync. As for design decisions, this is simply a first pass at the problem to try it out. BACKWARDS COMPATABILITY This change should be fully backwards compatible. REFERENCE IMPLEMENTATION Please see attached files. COPYRIGHT Public domain or whatever it needs to be to become part of Gentoo, any advice welcomed.
Created attachment 86718 [details, diff] warnme patch for emerge
Created attachment 86720 [details] Example package.warnme file
No need for two GLEPs here - see http://www.gentoo.org/proj/en/glep/glep-0042.html
(In reply to comment #0) Correction: examples: Trigger condition: >=app-crypt/gnupg-1.9 arch: x86 or ~x86
(In reply to comment #3) > No need for two GLEPs here - see > http://www.gentoo.org/proj/en/glep/glep-0042.html > Interesting but not quite the same thing.
Post sync hooks yes, more generic than warnings.
(In reply to comment #6) > Post sync hooks yes, more generic than warnings. That's interesting. This enhancement was to scratch a particular itch of mine but I'm all for abstracting up! Maybe the config file should be like: Trigger condition<white space>arch<white space>Action where "action" could be print a message or even run a program. I have to admit that, at the moment, I can't think of what someone would want to do post sync other than examine the changes to the packages but that's just my lack of imagination. Any ideas on what would make a suitable set of actions or do you have a different idea?
Now that portage-2.1 has gone stable this gives the possibility of using a post_sync hook which can be used for this function. As there doesn't appear to be much interest in this enhancement then I'' use the post_sync hook. Just in case anyone is interested I'll attach the code which you should save as /etc/portage/bin/post_sync and make sure the executable bit is set.
Created attachment 89339 [details] post_sync hook
I use this method to call more than one postsync action. shell $ cat /etc/portage/bin/post_sync #!/bin/sh # Copyright 2006 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: $ if [ -d /etc/portage/postsync.d/ ]; then for f in /etc/portage/postsync.d/* ; do if [ -x ${f} ] ; then ${f} fi done else : fi
(In reply to comment #10) Thanks solar, funnily enough I was starting to thing along similar lines and your post just saved me some time :-) Just one suggestion, emerge passes dosyncuri to the post_sync hook so I would use this code: #!/bin/sh # Copyright 2006 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: $ if [ -d /etc/portage/postsync.d/ ]; then for f in /etc/portage/postsync.d/* ; do if [ -x ${f} ] ; then ${f} $1 fi done else : fi I have implemented the above which works fine when running from a shell, however when being run from within emerge I get the following error: [Errno 9] Bad file descriptor: /bin/bash -c /etc/portage/bin/post_sync rsync://134.68.220.97/gentoo-portage I'm not sure what that's about. Finally I've made a small improvement to the code, previously the package.warnme file had to contain something like: >=media-video/nvidia-kernel-1.0.7167 x86 meaning trigger when nvidia-kernel goes stable on or greater than version 1.0.7167. Now you can do this as well: media-video/nvidia-kernel x86 meaning trigger when there is any stable version of nvidia-kernel (this is a silly example because there are already stable versions of this package). I've also tidied up the code a bit and changed its name because it now goes into the postsync.d directory.
Created attachment 89406 [details] post_sync update plus name change
that errno is probably coming from bug #136404
A postsync package has been added to the sunrise overlay.
post sync hooks have been available for some time now, think this bug can be closed
It doesn't seem to be documented, but the the hook can be any executable file located at /etc/portage/bin/post_sync. Apparently it's supported by >=portage-2.1.
(In reply to comment #16) > It doesn't seem to be documented, but the the hook can be any executable file > located at /etc/portage/bin/post_sync. Apparently it's supported by > >=portage-2.1. > As I mentioned in a previous post I have created a "postsync" package and placed the ebuild into the sunrise overlay. It currently has a couple of configurable post_sync actions, one of which is the warnme action but others could be added. I don't believe there's any reason to keep this bug open.
