1 |
Hi all, |
2 |
|
3 |
|
4 |
there is SoC idea on Gentoo wiki I am interested in. More specifically it's |
5 |
http://en.gentoo-wiki.com/wiki/2009_Summer_Of_Code_Ideas#Tree-wide_collision_checking_and_provided_files_database |
6 |
|
7 |
As far as I can understand there are these parts to this project: |
8 |
* use tinderbox to create builds of as much software from portage as possible |
9 |
* create remotely accessible database of files present in every |
10 |
installed package |
11 |
* create web interface for database |
12 |
* create tool that will provide users ability to do various stuff |
13 |
with that database (read-only) |
14 |
|
15 |
|
16 |
By "various stuff" I can think of these use cases: |
17 |
* will this package have any collisions on my system? |
18 |
* what files are in the package (depending on database maybe even |
19 |
depending on USE flags) |
20 |
* how big (aproximately) will be this package once installed? (I'd |
21 |
love to see this implemented some day) |
22 |
* report omissions in database |
23 |
* possibly many more (ideas welcome) |
24 |
I can also imagine QA could do quite a few things with this information. |
25 |
|
26 |
As always there is more than one approach to every part. |
27 |
|
28 |
For first part I can imagine distributed effort of general gentoo |
29 |
users. We could make optional feature in emerge (or other tool) that |
30 |
would send contents of each installed package (together with enabled |
31 |
use flags) to central server. This way we could possibly cover even |
32 |
differences between use flags. If we went down this road however there |
33 |
are quite a few privacy/security questions that would need to be |
34 |
answered. Or maybe I am missing something entirely and this is a |
35 |
braindead stupid idea :-) |
36 |
|
37 |
Lot of problems are of course related to building all the software |
38 |
(possibly on more architectures), sorting out build errors and related |
39 |
stuff. |
40 |
|
41 |
There are million things this infrastructure could be used for, once |
42 |
in place. I am sure most of use cases will pop up only after we |
43 |
implement basic idea. I believe usability of emerge could be improved |
44 |
a bit with this too. |
45 |
|
46 |
|
47 |
Let the brainstorm begin... |
48 |
|
49 |
|
50 |
Stanislav Ochotnicky |