1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
René 'Necoro' Neumann schrieb: |
5 |
> Ok ... some new points =): |
6 |
> |
7 |
> 1.) The dbus daemon is running the whole time the system is up, when |
8 |
> started once. Therefore the settings should be reloaded each time a |
9 |
> config file (/etc/portage/*, /etc/make.conf ...) is changed. I thought |
10 |
> of using inotify for this issue. Unfortunately, a well known editor |
11 |
> creates some problems: ViM (and I guess other editors behave similary): |
12 |
> It messes around and creates swap-files, temporary files - and instead |
13 |
> of modifying a file directly, it first moves it, then creates a new |
14 |
> modified one and finally deletes the old one (thus the inotify-watch is |
15 |
> gone afterwards). |
16 |
> The creation of the swap files is an issue, when watching a directory |
17 |
> for changes (e.g. /etc/portage). As the files are created _always_, the |
18 |
> settings would be reloaded even if the user only reads the files (and |
19 |
> another time, when he closes it, as the swap files are deleted). This is |
20 |
> definitly a non-optimal solution. |
21 |
|
22 |
I finally solved that issue: |
23 |
Now all events occuring at watched pathes are checked whether they refer |
24 |
to a temporary file. If this is true, they are ignored. |
25 |
|
26 |
A temporary file is defined as: |
27 |
- - either ends or starts with "#" |
28 |
- - is a hidden file (starts with ".") |
29 |
- - is a backup file (ends with "~" or ".bkp") |
30 |
- - consits only of digits (yes ViM does such crazy stuff) |
31 |
|
32 |
And to reduce the reload-calls even more: All events that trigger a |
33 |
reload in a specific time frame (at the moment: 2 seconds) are taken as |
34 |
one trigger. |
35 |
|
36 |
> |
37 |
> 2.) If noone objects in the following days, I would like to write to the |
38 |
> portage-dev-ml about this project (or better: the plans of the project) |
39 |
> and perhaps get some proposals from this side :) |
40 |
|
41 |
this is still a todo. |
42 |
|
43 |
> 3.) As it is quite some work to maintain two versions of the |
44 |
> portage-backend, I plan to use catapult in Portato by default. But this |
45 |
> depends on how soon we find a solution for 1.). |
46 |
|
47 |
Catapult now seems quite reliable. Some functionality still has to be |
48 |
implemented: |
49 |
|
50 |
- - different API versions (*) |
51 |
- - central library (for use flags, central administration etc) (*) |
52 |
- - allow the server to be stopped from outside. this is esp. important |
53 |
when installing a new version - the old version running should then stop |
54 |
and the new one should start ;) |
55 |
- - extended API ... if there are no more API requests I will take the API |
56 |
as version 0 and all future extensions will be API v1. |
57 |
|
58 |
(*): not a blocker: so if this cannot be done in time, it can be delayed |
59 |
|
60 |
@araujo: How are the chances that catapult can get into tree in some |
61 |
weeks? - Would you (proxy-)maintain it? |
62 |
If yes, the next portato version (which will come in like 3 to 4 weeks I |
63 |
hope) would only use catapult as backend (except of course another major |
64 |
bug occurs). |
65 |
|
66 |
This would allow me, to focus on maintaining the catapult backend and |
67 |
not having to deal with two things. (For example the update_world needs |
68 |
some extension...) |
69 |
|
70 |
Regards, |
71 |
Necoro |
72 |
-----BEGIN PGP SIGNATURE----- |
73 |
Version: GnuPG v1.4.7 (GNU/Linux) |
74 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org |
75 |
|
76 |
iD8DBQFHK2gZ4UOg/zhYFuARArVSAJwMZGGKhtN19/+Xg49eM5iTE+1IvwCfRVTO |
77 |
adrteqWShmv0eXGIQnpSW6o= |
78 |
=4CF5 |
79 |
-----END PGP SIGNATURE----- |
80 |
-- |
81 |
gentoo-guis@g.o mailing list |