1 |
> I quickly glanced over your proposal. Here are some questions: |
2 |
> - how often is "often" in "on unstable branch compiling often fails |
3 |
> due.." |
4 |
This happens one time in 2-3 weeks. I use Gentoo as my main operating |
5 |
system and have very many packages installed(and many of them are from |
6 |
overlays). For some time I was finding a problem source on |
7 |
bugs.gentoo.org, and was patching an ebuilds locally. Now I adding |
8 |
fails versions of packages in package.mask. These packages becoming a |
9 |
problem especially often: media-libs/libpng, x11-libs/cairo, |
10 |
dev-libs/DirectFB, media-gfx/imagemagick(periodically brakes |
11 |
inkscape). |
12 |
|
13 |
> - have you looked into the preseved-libs feature of Portage-2.2? you may |
14 |
> want to at least refer to it in your proposal |
15 |
Yes, I met with it from the user's side. I think it is a genius |
16 |
feature, most desktop applications should not work without it after |
17 |
updating a lib. This feature covers majority of runtime dependencies |
18 |
problems. But some problems are left. For example, when I install a |
19 |
new linux kernel, I need to recompile virtualbox-modules, when I |
20 |
update perl of python, I need to recompile all perl or python modules |
21 |
manually. |
22 |
|
23 |
I want to focus on build time dependencies problem. |
24 |
|
25 |
> - why are files accessed during a build important for the end-product? |
26 |
There is a big correlation between files, accessed during a build and |
27 |
build-time dependencies of the package. An example case: Package A |
28 |
depends on package B. Package B consists of .h files. During the build |
29 |
of package A having an access to package B's file xf86vmode.h. Package |
30 |
B is available in 2 versions: 1.0 with the file xf86vmode.h and 2.0, |
31 |
where xf86vmode.h was renamed in xf86vm.h. Dependency builder will be |
32 |
able to notify package developer about a possible breakage. |
33 |
|
34 |
Dependency checker may not just block any operations on files not |
35 |
belonging to one of dependency packages. It may allow writings, but |
36 |
with the possibility to discard a changes(snapshotting). With the FUSE |
37 |
help it is not very hard to code. It will allow to test package |
38 |
building and runtime working in particular environment. |
39 |
|
40 |
> - where do you intent to run this dependency builder (or by who)? |
41 |
I am want to create tool for developers of packages. |
42 |
It is possible to write auto build tester and dependency builder for |
43 |
all new packages, but I think that a computer system(even distributed) |
44 |
will not have a time to test such volume of packages. |
45 |
|
46 |
Also, database [package->[files in package]] and [package->[files |
47 |
accessed during building this package]] can be useful for advanced |
48 |
users for searching a package having some file, like /usr/bin/mpirun |
49 |
or /sbin/iwconfig. |
50 |
|
51 |
> - why is "Autodetecting a compatible versions of libs" a problem at all? |
52 |
> do you want to go further than assuming the soname of the shared |
53 |
> library identifies compatability? (I think that should be a separate |
54 |
> issue) |
55 |
I am mostly talking about build time dependencies. The build may fail |
56 |
on linking stage, when an application try to use a function, which is |
57 |
no exported in old-version library. More generally, it is not problem |
58 |
of libs versions, it is a problem of versions of dependencies. |
59 |
|
60 |
> - what benefit does a nosql "database" give you in your proposal? |
61 |
I hope this approach will have better performance and scalability. I |
62 |
have a big experience in SQL and no experience in NoSQL. I want to |
63 |
test a NoSQL approach to have that experience. If it will a bad |
64 |
experience I switch to SQL. |
65 |
|
66 |
I need to store a data: [package->[files in package]] and |
67 |
[package->[files accessed during building this package]]. A am afraid, |
68 |
that operation: [files accessed during building a |
69 |
package]->[dependencies of a package] will be very memory and CPU |
70 |
expensive if to use a traditional JOIN. |
71 |
|
72 |
> - can you make rough estimations of the storage space necessary on the |
73 |
> client side? |
74 |
Raw building log takes about 15MB of disk space. Most of it is |
75 |
garbage. I think it can be compressed to 3-100KB per package. |
76 |
|
77 |
All base will take a few GB of disk space. I want to give to user a |
78 |
choice: download full base or download parts of it on demand. |
79 |
|
80 |
Thank you for your questions. |
81 |
|
82 |
Best, |
83 |
|
84 |
Alexander Bersenev |