Gentoo Archives: gentoo-soc

From: "Stanislav Ochotnický" <sochotnicky@×××××.com>
To: gentoo-soc@l.g.o
Subject: [gentoo-soc] Application for "Tree-wide collision checking and provided files database"
Date: Fri, 03 Apr 2009 13:15:28
Message-Id: 7943d9c10904030615y1a06fc6dw961cf3cb0f90838c@mail.gmail.com
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