Gentoo Archives: gentoo-guis

From: "René 'Necoro' Neumann" <lists@××××××.eu>
To: gentoo-guis@l.g.o
Subject: Re: [gentoo-guis] One backend for alle portage GUIs
Date: Fri, 02 Nov 2007 18:11:07
In Reply to: Re: [gentoo-guis] One backend for alle portage GUIs by "René 'Necoro' Neumann"
Hash: SHA1

René 'Necoro' Neumann schrieb:
> 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 - iD8DBQFHK2gZ4UOg/zhYFuARArVSAJwMZGGKhtN19/+Xg49eM5iTE+1IvwCfRVTO adrteqWShmv0eXGIQnpSW6o= =4CF5 -----END PGP SIGNATURE----- -- gentoo-guis@g.o mailing list


Subject Author
Re: [gentoo-guis] One backend for alle portage GUIs "René 'Necoro' Neumann" <lists@××××××.eu>