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