1 |
On 23/03/06, Paul de Vrieze <pauldv@g.o> wrote: |
2 |
> |
3 |
> Certainly, |
4 |
> |
5 |
> chroot combined with lvm snapshots would be the easiest way. |
6 |
> |
7 |
> If you want to focus on binary packages, you might want to start with not |
8 |
> doing it automatically, but using some crude heuristics. You can make it |
9 |
> configurable for when the heuristics don't work. |
10 |
> |
11 |
> Basically what is the difference between a binary package and the source |
12 |
> package is the dependencies. |
13 |
> |
14 |
> You can regard a dependency as a restriction on the configurations in |
15 |
> which |
16 |
> the package can be installed. For binary packages only runtime |
17 |
> dependencies |
18 |
> are relevant (well in gentoo anyway, we don't have initial configuration |
19 |
> deps). Binary packages do however further restrict the configurations from |
20 |
> the runtime dependencies. These restrictions originate from the |
21 |
> configuration |
22 |
> when compiling the package. |
23 |
> |
24 |
> Then I have some good and bad news. The good news: |
25 |
> - Binary dependencies are as necessary for binary packages, as for |
26 |
> validating |
27 |
> a current configuration (set of installed packages). |
28 |
> The bad: |
29 |
> - For proper binary dependencies the depend expression possibilities must |
30 |
> be |
31 |
> extended. Useflag dependencies would be at least usefull. BINSLOT would |
32 |
> be |
33 |
> almost required. We already saw that SLOT can't always be used for |
34 |
> BINSLOT. |
35 |
|
36 |
|
37 |
BINSLOT is a new word for me. |
38 |
|
39 |
I dont see any meaning in calculating dependencies after build. There would |
40 |
be too much problems: |
41 |
* If any of packages you depend on, are masked, you get an error after |
42 |
build, but should get it before |
43 |
* In many cases, not only libs, but also headers are included from another |
44 |
pack [kernel headers, for example, as i have seen from error messages] |
45 |
* You cant pre-calculate dependancies |
46 |
|
47 |
My interest, for sure, is code dependancies. At first i see a clear way to |
48 |
get it work for now, secondly i think it can be used for bin deps, also. |
49 |
|
50 |
In cases, where both headers and libs are included from other pack, which is |
51 |
same on both cases, this is totally irrelevant for deps if this other pack |
52 |
is statically or dynamically used. |
53 |
|
54 |
In cases, where headers are in pack to be compiled and .so is in another |
55 |
package, i havent yet checked, how to understand if dependancy is binary -- |
56 |
i cant say for sure that this does not include some work from user. |
57 |
|
58 |
Ok, i better write few lines of code now as i know where i should start (or |
59 |
at least i have one part of code, which could be discussed here, in front of |
60 |
my minds-eye). |
61 |
|
62 |
Thanks. You will understand me better when something works :) |
63 |
|
64 |
Paul |
65 |
> |
66 |
> -- |
67 |
> Paul de Vrieze |
68 |
> Gentoo Developer |
69 |
> Mail: pauldv@g.o |
70 |
> Homepage: http://www.devrieze.net |
71 |
> |
72 |
> |
73 |
> |
74 |
|
75 |
|
76 |
-- |
77 |
tvali |
78 |
|
79 |
Measuring programming progress by lines of code is like measuring aircraft |
80 |
building progress by weight. -Bill Gates |
81 |
|
82 |
For every complex problem there is an answer that is clear, simple, and |
83 |
wrong. -H L Mencken |
84 |
|
85 |
Theory is when you know something, but it doesn't work. Practice is when |
86 |
something works, but you don't know why. Programmers combine theory and |
87 |
practice: Nothing works and they don't know why. |
88 |
|
89 |
http://www.eskimo.com/~hottub/software/programming_quotes.html |
90 |
http://www.softwarequotes.com/ |