default postsync

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 $ ] ; then
                        $
                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..

-- 
Ned Ludd <solargentoo.org>
Gentoo Linux

-- 
gentoo-portage-devgentoo.org mailing list

Ned Ludd wrote:
> #!/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 $ ] ; then
>                         $
>                 fi
>         done
> else
>         :
> fi
> ##############################
> 
> How do you think we should handle it?

I'd prefer this way:

----
#!/bin/sh
# Copyright 2006 Gentoo Foundation
# Distributed under the terms of the GNU General Public
License v2
# $Header: $

if [ -f /etc/portage/bashrc ]; then
	source /etc/portage/bashrc
	[ "$(type -t post_sync)" ==
"function" ] && post_sync
fi
----

i.e. use bashrc for this. We handle the existing hooks
through bashrc, 
and postsync hooks aren't anything different, so they
should be handled 
through the same logic. I think it's just more intuitive
than a 
postsync.d/ subdirectory.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-portage-devgentoo.org mailing list

On Thu, 2006-05-04 at 22:36 +0200, Simon Stelling wrote:
> Ned Ludd wrote:
> > #!/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 $ ] ; then
> >                         $
> >                 fi
> >         done
> > else
> >         :
> > fi
> > ##############################
> > 
> > How do you think we should handle it?
> 
> I'd prefer this way:
> 
> ----
> #!/bin/sh
> # Copyright 2006 Gentoo Foundation
> # Distributed under the terms of the GNU General Public
License v2
> # $Header: $
> 
> if [ -f /etc/portage/bashrc ]; then
> 	source /etc/portage/bashrc
> 	[ "$(type -t post_sync)" ==
"function" ] && post_sync
> fi
> ----
> 
> i.e. use bashrc for this. We handle the existing hooks
through bashrc, 
> and postsync hooks aren't anything different, so they
should be handled 
> through the same logic. I think it's just more
intuitive than a 
> postsync.d/ subdirectory.

The post_sync action already exists in both 2.0 and 2.1 
This mail is about extending it before it becomes wide
spread to 
include more than 1 action.

I'm thinking bashrc is not really the right place for this
cuz there is
no $EBUILD_PHASE and everything todo with bashrc to date has
always 
been fed a PHASE where things like $PN / $PV / $D / $EBUILD
etc are set.
post sync actions are completely separate from ebuilds on
the 
individual level.

Honestly I'm thinking more on the lines of this is best
suited for 
4-5 lines of python.

-peace.


> -- 
> Kind Regards,
> 
> Simon Stelling
> Gentoo/AMD64 Developer
-- 
Ned Ludd <solargentoo.org>
Gentoo Linux

-- 
gentoo-portage-devgentoo.org mailing list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ned Ludd wrote:
> 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..


Given the existing support for /etc/portage/bin/post_sync,
the user has the freedom to do anything they want.  If a
program needs to make use of the post_sync trigger, it's
documentation can simply state that a certain command needs
the be run and the user can add that command to their
post_sync script.  Is that not easy and flexible enough?

Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEWsnT/ejvha5XGaMRAmOsAKDTaCc4GA16hO4o24OKxOqkTFhbLgCg
uQEA
cxh1Y3+c/o4CGWcnc+Jh8zY=
=7K0g
-----END PGP SIGNATURE-----
-- 
gentoo-portage-devgentoo.org mailing list

Zac Medico schrieb:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Ned Ludd wrote:
>> 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..
> 
> 
> Given the existing support for
/etc/portage/bin/post_sync, the user has the freedom to do
anything they want.  If a program needs to make use of the
post_sync trigger, it's documentation can simply state that
a certain command needs the be run and the user can add that
command to their post_sync script.  Is that not easy and
flexible enough?

Well, it requires user intervention, pretty much the same
argument as 
for any other foo.d change in any package (I don't have a
personal 
preference here, though using bashrc for this definitely
isn't a good idea).

Marius
-- 
gentoo-portage-devgentoo.org mailing list