Hi,
I think this is a good idea. Now that we have the file installed by
portage-utils there are ideas spreading about using it in layman and eix.
Depending on portage-utils does not seem to be a good way to make sure that
the bin/post_sync file exists. Installing it on ou one neither, because of
collissions. So the best solution is to allow portage to provide this file.
Please add it
Best regards,
Stefan
Ned Ludd wrote:
> Jason and myself had talked about briefly but not in any depth about
> post sync actions. Quickly after the basic idea was accepted it
> started to become clear that a set of default triggered may be
> desired.
> So I was thinking like if portage installed something like the
> following or if we changed the behavior now in emerge.py before the
> existing become to widely adopted to do more or less the same thing
> that this bash script does.
>
> #!/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
> ##############################
>
> How do you think we should handle it?
> Should we install a post_sync in a postinst phase outside of portage's
> handling if and only if not post_sync already exists?
> Should we change it to handled a postsync.d by default?
> Should we do both? I'm open as heck but would like to start to
> finalize then document it's behavior. I feel it could be one of the
> next untapped really useful features of portage. glsa-checking, news
> handling, search db updating, and stuff etc..
>
--
gentoo-portage-dev@gentoo.org mailing list
