1 |
There is one clear problem: |
2 |
|
3 |
1. Some other app opens some portage file. |
4 |
2. Tree is mounted and indexed. |
5 |
3. Other app changes this file. |
6 |
4. Index is out-of-date. |
7 |
|
8 |
To disallow such thing it should be first suggested that all scripts change |
9 |
portage tree only after mount. As defence against those, which dont listen |
10 |
to that suggestion, portage should just not use this altered data - portage |
11 |
should totally rely on it's internal index and when you change some file and |
12 |
index is not updated, you change should be as well as lost. Does this make |
13 |
portage tree twice as big as it is? |
14 |
|
15 |
I guess not, because: |
16 |
|
17 |
- Useflags can be indexed and refferred with numbers. |
18 |
- Licence, homepage and such data is not needed to be duplicated. |
19 |
|
20 |
Also, as overlay directories are suggested anyway, is it needed at all to |
21 |
check *all* files for updates? I think that when one does something wrong, |
22 |
it's OK when everything goes boom and if someone has update scripts, which |
23 |
dont use overlays and other suggested ways to do thing, then adding one more |
24 |
thing, which breaks, is not bad. Hashing those few files isnt bad idea and |
25 |
keeping internal duplicate of overlay directory is not so bad, too - then |
26 |
you need to "emerge --commithandmadeupdates" and that's all. |
27 |
|
28 |
Some things, which could be used to boost: |
29 |
|
30 |
- Dependancy searches are saved - so that "emerge -p pck1 pck2 pck3" |
31 |
saves data about deps of those 3 packages. |
32 |
- Package name list is saved. |
33 |
- All packages are given integer ID. |
34 |
- List of all words in package descriptions are saved and connected to |
35 |
their internal ID's. This could be used to make smaller index file. So when |
36 |
i search for "al", then all words containing those chars like "all" are |
37 |
considered and -S search will run only on those packages. |
38 |
- Hash file of whole portage tree is saved to understand if it's changed |
39 |
after last remount. |
40 |
|
41 |
2008/11/24 tvali <qtvali@×××××.com> |
42 |
|
43 |
> So, mornings are smarter than evenings (it's Estonian saying) ...at night, |
44 |
> I thought more about this filesystem thing and found that it simply answers |
45 |
> all needs, actually. Now I did read some messages here and thought how it |
46 |
> could be made real simple, at least as I understand this word. Yesterday I |
47 |
> searched if custom filesystems could have custom functionality and did not |
48 |
> find any, so I wrote this list of big bunch of classes, which might be |
49 |
> overkill as I think now. |
50 |
> |
51 |
> First thing about that indexing - if you dont create daemon nor filesystem, |
52 |
> you can create commands "emerge --indexon", "emerge --indexoff", "emerge |
53 |
> --indexrenew". Then, index is renewed on "emerge --sync" and such, but when |
54 |
> user changes files manually, she has to renew index manually - not much |
55 |
> asked, isn't it? If someone is going to open the cover of her computer, she |
56 |
> will take the responsibility to know some basic things about electricity and |
57 |
> that they should change smth in bios after adding and removing some parts of |
58 |
> computer. Maybe it should even be "emerge --commithandmadechanges", which |
59 |
> will index or do some other things, which are needed after handmade changes. |
60 |
> More such things might emerge in future, I guess. |
61 |
> |
62 |
> But about filesystem... |
63 |
> |
64 |
> Consider such thing that when you have filesystem, you might have some |
65 |
> directory, which you could not list, but where you can read files. Imagine |
66 |
> some function, which is able to encode and decode queryes into filesystem |
67 |
> format. |
68 |
> |
69 |
> If you have such function: search(packagename, "dependencies") you can |
70 |
> write it as file path: |
71 |
> /cgi-bin/search/packagename/dependencies - and packagename can be encoded |
72 |
> by replacing some characters with some codes and separating long strings |
73 |
> with /. Also, you could have API, which has one file in directory, from |
74 |
> where you can read some tmp filename, then write your query to that file and |
75 |
> read the result from the same or similarly-named file with different |
76 |
> extension. So, FS provides some ways to create custom queries - actually |
77 |
> that idea came because there was idea of creating FS as cgi server on LUFS |
78 |
> page, thus this "cgi-bin" starting here is to simplify. I think it's similar |
79 |
> to how files in /dev/ directory behave - you open some file and start |
80 |
> writing and reading, but this file actually is zero-sized and contains |
81 |
> nothing. |
82 |
> |
83 |
> Under such case, API could be written to provide this filesystem and |
84 |
> nothing more. If it is custom-mapped filesystem, then it could provide |
85 |
> search and such directories, which can be used by portage and others. If |
86 |
> not, it would work as it used to. |
87 |
> |
88 |
> So, having filesystem, which contains such stuff (i call this subdir "dev" |
89 |
> here): |
90 |
> |
91 |
> - /dev/search - write your query here and read the result. |
92 |
> - /dev/search/searchstring - another way for user to just read some |
93 |
> listings with her custom script. |
94 |
> - /portage/directory/category/packagename/depslist.dev - contains |
95 |
> dynamic list of package dependencies. |
96 |
> - /dev/version - some integer, which will grow every time any change to |
97 |
> portage tree is made. |
98 |
> |
99 |
> Then, other functions would be added eventually. |
100 |
> |
101 |
> Now, things simple: |
102 |
> |
103 |
> - Create standard filesystem, which can be used to contain portage |
104 |
> tree. |
105 |
> - Add all nessecary notifications to change and update files. |
106 |
> - *Mount this filesystem to the same dir, where actual files are placed |
107 |
> - if it's not mounted, portage will almost not notice this (so in emergency, |
108 |
> things are just slower). You can navigate to a directory, then mount new one |
109 |
> - I am not on linux box right now, but if I remember correctly, you can use |
110 |
> files in real directory after mounting smth other there in such way.* |
111 |
> - Create indexes and other stuff. |
112 |
> |
113 |
> 2008/11/24 Fabian Groffen <grobian@g.o> |
114 |
> |
115 |
> On 24-11-2008 10:34:28 +0100, René 'Necoro' Neumann wrote: |
116 |
>> > tvali schrieb: |
117 |
>> > > There is daemon, which notices about filesystem changes - |
118 |
>> > > http://pyinotify.sourceforge.net/ would be a good choice. |
119 |
>> > |
120 |
>> > Disadvantage: Has to run all the time (I see already some people crying: |
121 |
>> > "oh noez. not yet another daemon..."). |
122 |
>> |
123 |
>> ... and it is Linux only, which spoils the fun. |
124 |
>> |
125 |
>> |
126 |
>> -- |
127 |
>> Fabian Groffen |
128 |
>> Gentoo on a different level |
129 |
>> |
130 |
>> |
131 |
> |
132 |
> |
133 |
> -- |
134 |
> tvali |
135 |
> |
136 |
> Kuskilt foorumist: http://www.cooltests.com - kui inglise keelt oskad. |
137 |
> Muide, üle 120 oled väga tark, üle 140 oled geenius, mingi 170 oled ju mingi |
138 |
> täica pea nagu prügikast... |
139 |
> |
140 |
|
141 |
|
142 |
|
143 |
-- |
144 |
tvali |
145 |
|
146 |
Kuskilt foorumist: http://www.cooltests.com - kui inglise keelt oskad. |
147 |
Muide, üle 120 oled väga tark, üle 140 oled geenius, mingi 170 oled ju mingi |
148 |
täica pea nagu prügikast... |