> Ok ... some new points =):
>
> 1.) The dbus daemon is running the whole time the system is up, when
> started once. Therefore the settings should be reloaded each time a
> config file (/etc/portage/*, /etc/make.conf ...) is changed. I thought
> of using inotify for this issue. Unfortunately, a well known editor
> creates some problems: ViM (and I guess other editors behave similary):
> It messes around and creates swap-files, temporary files - and instead
> of modifying a file directly, it first moves it, then creates a new
> modified one and finally deletes the old one (thus the inotify-watch is
> gone afterwards).
> The creation of the swap files is an issue, when watching a directory
> for changes (e.g. /etc/portage). As the files are created _always_, the
> settings would be reloaded even if the user only reads the files (and
> another time, when he closes it, as the swap files are deleted). This is
> definitly a non-optimal solution.

I finally solved that issue:
Now all events occuring at watched pathes are checked whether they refer
to a temporary file. If this is true, they are ignored.
A temporary file is defined as:
- - either ends or starts with "#"
- - is a hidden file (starts with ".")
- - is a backup file (ends with "~" or ".bkp")
- - consits only of digits (yes ViM does such crazy stuff)
And to reduce the reload-calls even more: All events that trigger a
reload in a specific time frame (at the moment: 2 seconds) are taken as
one trigger.

>
> 2.) If noone objects in the following days, I would like to write to the
> portage-dev-ml about this project (or better: the plans of the project)
> and perhaps get some proposals from this side :)

this is still a todo.

> 3.) As it is quite some work to maintain two versions of the
> portage-backend, I plan to use catapult in Portato by default. But this
> depends on how soon we find a solution for 1.).

Catapult now seems quite reliable. Some functionality still has to be
implemented:
- - different API versions (*)
- - central library (for use flags, central administration etc) (*)
- - allow the server to be stopped from outside. this is esp. important
when installing a new version - the old version running should then stop
and the new one should start ;)
- - extended API ... if there are no more API requests I will take the API
as version 0 and all future extensions will be API v1.
(*): not a blocker: so if this cannot be done in time, it can be delayed
@araujo: How are the chances that catapult can get into tree in some
weeks? - Would you (proxy-)maintain it?
If yes, the next portato version (which will come in like 3 to 4 weeks I
hope) would only use catapult as backend (except of course another major
bug occurs).
This would allow me, to focus on maintaining the catapult backend and
not having to deal with two things. (For example the update_world needs
some extension...)
Regards,
Necoro
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHK2gZ4UOg/zhYFuARArVSAJwMZGGKhtN19/+Xg49eM5iTE+1IvwCfRVTO
adrteqWShmv0eXGIQnpSW6o=
=4CF5
-----END PGP SIGNATURE-----
--
gentoo-guis@g.o mailing list