| 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 |
Archives