1 |
Hi everyone, |
2 |
|
3 |
I am applying for gentoo SoC project idea "Tree-wide collision |
4 |
checking and provided files database". This is my student application, |
5 |
which you can read also here: |
6 |
http://student.fiit.stuba.sk/~ochotnic04/files/sochotnicky_gsoc_application.pdf |
7 |
|
8 |
I am welcome to suggestions to improve it (however with so little time |
9 |
I do not really expect anything major :-) ). |
10 |
|
11 |
|
12 |
*Project mission* |
13 |
|
14 |
Main goal of this project is to create easy way for Gentoo developers |
15 |
to maintain database of files present in packages residing in Portage |
16 |
tree. This will open new possibilities for both Gentoo team and users |
17 |
alike. Gentoo QA team will be able to improve existing ebuilds and |
18 |
common users will be able to check package contents before installing |
19 |
packages. |
20 |
|
21 |
*Abstract* |
22 |
|
23 |
Gentoo emerge is checking for file collisions before installing |
24 |
packages. However this collision checking only works after package has |
25 |
been compiled. This is natural since Gentoo is source based and |
26 |
package contents are different for every architecture, set of USE |
27 |
flags and compiler options. Proposed project would provide users and |
28 |
more importantly Gentoo QA team access to database of files in |
29 |
packages from Portage tree. Information about package contents would |
30 |
enable Gentoo QA team to improve existing ebuilds by solving problems |
31 |
resulting from collisions. Users would be also able to see approximate |
32 |
size of package and query package contents before installing it. When |
33 |
invoking non-existing command on shell, shell handler could check file |
34 |
database and offer packages to install. There are definitely other |
35 |
uses waiting to be discovered. |
36 |
|
37 |
*Deliverables* |
38 |
|
39 |
** Tool for aggregating package contents ** |
40 |
|
41 |
Also information from stat() sycall for files. Most probably this part |
42 |
will be database and wrapper set of tools. More sources of package |
43 |
contents would be possible: |
44 |
|
45 |
1. tinderbox set-up exactly to collect this information |
46 |
(semi-automatic, fixing compile errors manually) |
47 |
|
48 |
2. binary packages (perhaps interaction with GSoC project |
49 |
Improved binary package support?) |
50 |
|
51 |
3. restricted user supplied package contents (this would need |
52 |
to be analyzed more deeply from security/privacy point of view) |
53 |
|
54 |
Public API for read-only access and/or commiting package contents |
55 |
could be provided depending on analysis and gentoo team preferences. |
56 |
|
57 |
** Web interface for package contents database ** |
58 |
|
59 |
After database of packages is succesfully created this web interface |
60 |
would provide world-readable access to package contents through web |
61 |
browser with ability to search for files and packages. |
62 |
|
63 |
** Console tool for querying package contents ** |
64 |
|
65 |
Depending on the size of database, it could be downloaded from server |
66 |
or client could query public server for package contents and/or other |
67 |
information provided. I would like to keep dependencies of this tool |
68 |
to the minimum (Python, depending on the database format maybe |
69 |
sqlite). |
70 |
|
71 |
All deliverables will include documentation. |
72 |
|
73 |
|
74 |
* Timeline * |
75 |
|
76 |
15. April - 23. May: Getting to know Gentoo community spirit a bit |
77 |
more and some lightweight design discussions for first deliverable |
78 |
|
79 |
24. May - 7. June (2 weeks): Discussion to design first deliverable |
80 |
|
81 |
8. June - 21. June (2 weeks): Coding First deliverable with basic |
82 |
documentation and design for 2nd and 3rd deliverable |
83 |
|
84 |
22. June - 13. July (3 weeks): Second deliverable (web interface) |
85 |
|
86 |
14. July - 4. August (3 weeks): Third deliverable coding (client utility) |
87 |
|
88 |
4. August - 17. August (2 weeks): Finalizing, fixing bugs, cleaning up |
89 |
code and documentation |
90 |
|
91 |
Obviously this is only very rough idea. Lot of things will depend on |
92 |
analysis and design decisions for first deliverable. |
93 |
|
94 |
* Biography* |
95 |
|
96 |
I am grad student at Slovak University of Technology in Bratislava |
97 |
studying Software Engineering. I have participaded on few OSS projects |
98 |
(musicpd, gstfs, gstreamer) before, mostly with bugreports and |
99 |
(admittedly very few) patches. My bachelor's project was "Userspace |
100 |
process access restriction in Linux and FreeBSD". I am quite confident |
101 |
with C/C++, Java, basic shell scripting and Python. I have also used |
102 |
quite a few other technologies, but usually only for one or two |
103 |
projects. Of course I would like to learn more and try something new. |
104 |
As far as my Linux usage goes, I have been happy Gentoo user for |
105 |
almost 4 years now. Before that I used Linux From Scratch based |
106 |
distribution for one year, so I have a lot of experience with build |
107 |
errors, which should come in handy :-). |
108 |
|
109 |
My work experience includes participation on coding part of Ripple |
110 |
control system for energetics companies (together with more smaller |
111 |
projects for MicroStep-HDO, Slovakia). I've also spent 6 months as |
112 |
intern in Edisoft (Portugal) where I worked on model-driven |
113 |
development tool for FPGAs. |
114 |
|
115 |
|
116 |
-- |
117 |
Stanislav Ochotnicky |