Re: Re: ebuilds in XML

>
>> - the 'hook' for security updates is in my mind completely separate
>> from
>> portage. just a little daemon listening on a port should suffice,
>> right?
>> it can spawn whatever it likes when something tells it to. the other
>> option is to add a server component to portage and let the portage
>> engine be a daemon. i've considered this path before, but it would
>> require pushing a good amount of the functionality of emerge into the
>> portage module due to performance reasons.
>>
>
>
> hmmm ok.  I will trust your better judgment on this.  I just feel
> strongly that this funtionality has to be there.  Would this external
> app also be able to revoke ebuilds and such?  This is a crucial part of
> this strategy as well.
>

i agree the functionality needs to be there too. it's just a question of
how to implement it. 3 possibilities immediately come to mind:

1. the one i suggested where you pass things like "emerge -u foo" to a
small server running on the client and it executes that command. it would
be more secure than just being able to run random commands on a remote
system, but that's the idea.

2. have a server that actually has an embedded portage engine in it. the
client would then effectively be /usr/bin/emerge with the ability to talk
to a remote portage engine. it would call functions in that engine (using
RPC/corba/custom code/whatever). i looked briefly at the communication
between /usr/bin/emerge and the portage engine and the traffic was very
high (granted this was a worst case 'emerge -S foo' analysis). this is wh=
y
i previously suggested option 1 above as this solution might involve a lo=
t
of unecessary network traffic.

3. a mix of 1 and 2. you do RPC calls into the server, but the calls are
of a very high level. this option would be sort of like exporting the
functionality of /usr/bin/emerge as RPC calls.


please comment on any of the above. i'm not sure what you meant by
'revoking ebuilds'.

thanks.
nall.