Gentoo Archives: gentoo-portage-dev

From: Pieter Van den Abeele <pvdabeel@g.o>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] Multiple language use, `component-based' design, and other issues
Date: Mon, 12 Jan 2004 09:17:39
In Reply to: [gentoo-portage-dev] Multiple language use, `component-based' design, and other issues by Jeremy Maitin-Shepard
1 Hi,
3 On 12 Jan 2004, at 06:14, Jeremy Maitin-Shepard wrote:
5 > The main advantage cited for using multiple languages has been that
6 > certain languages are `better' for doing certain types of things. For
7 > example, it has been argued that Prolog should be used for dependency
8 > calculation because programs written in it can be proven correct. I
9 > fail to understand why it is particularly important that the portage
10 > dependency checker be ``provably correct.'' To my knowledge, there
11 > have
12 > been no significant problems with there being bugs in the current
13 > dependency checker. It is also useful to note that there are tens of
14 > thousands or more software programs, far more critical than a portage
15 > dependency checker, which are not written in languages in which they
16 > can
17 > be proven correct, but which operate quite adequately. It is perhaps
18 > useful for the software on the Spirit Mars rover to be provably
19 > correct,
20 > but that is simply not a useful guideline for the portage dependency
21 > checker. It has also been argued that it is more convenient to write a
22 > dependency checker in Prolog, compared to other languages. I can
23 > assure the reader that implementing a topological sort algorithm in any
24 > language is not overly complex; certainly not sufficiently complex to
25 > justify doing it in another language and dealing with language
26 > interoperability problems and adding an additional compile-time and
27 > possibly runtime dependency.
29 Ah, this is a common misconception. It is true that a topological sort
30 can be realized in every language. There is certainly no clear
31 advantage of using prolog for that. However, what happens -before-
32 applying that ordering and which is often forgotten, is 'computing a
33 configuration' or 'computing a model' if you prefer. Let me explain
34 with a simplified example.
36 Right now current portage performs a walk through the dependency graph.
37 Please consider the following simplified example:
39 kde -> linux.
40 kde -> bsd.
42 means that kde depends on either linux or bsd. So if a user told
43 portage he/she wanted kde, portage could suggest either linux or bsd.
44 However if a user also told portage he/she wanted component 'foo' and
45 it is known that
47 'foo cannot be installed on bsd'
49 the bsd option for kde is no longer a relevant option, because it is
50 excluded by a constraint introduced by adding foo to the configuration.
51 Portage currently does not feature such constraints (which are quite
52 similar to the 'conflict field used in debian packages'. I think it
53 will be hard to implement similar behaviour. Also, this is a simplified
54 example. An example from real life shows that:
56 kde -> qt(use kde)
58 So if you want to install kde, qt should be installed with option 'kde'
59 enabled. But similarily, a component should be able to constrain use
60 flags of another package. Or a combination of components could be
61 constrained, ...
63 Reasoning about these things is much much easier in something like
64 prolog. But the real advantage here is that prolog can be regarded as a
65 proof engine and thus is able to provide a proof why a component with a
66 given specification is in a configuration. It is important to ensure
67 that the configuration returned is correct and satisfies user
68 constraints/requirements. So in that sense, it will be 'provable'. But
69 again, I don't see prolog as an absolute requirement; everything which
70 provides the equivalent of a Turing Machine should can be used to
71 implement what I'm doing now in Prolog. The set of features that can be
72 reused in prolog happens to be bigger than for instance C++ or anything
73 else for this problem, which speeds up development of an explicatory
74 prototype.
76 > It has been mentioned that portage-ng will have a `component-based'
77 > design. It is not clear what the term `component-based' means exactly,
78 > and so it would be useful to get some clarification. To me that term
79 > suggests that portage-ng will use some sort of complex runtime dynamic
80 > linking model. I would argue that it may be simpler to simply handle
81 > all optional functionality, if there is any, through the use of USE
82 > flags, rather than going to the trouble of supporting such a complex
83 > model. Clearly, some type of static linking could only be supported if
84 > portage-ng did not depend on a runtime dynamic linking model.
85 > Advantages to allow static linking include greater robustness in cases
86 > of failure of various shared libraries, and the dependencies of portage
87 > will not need to be handled as carefully, because there will be no risk
88 > of breaking a statically-linked portage.
90 You make some valid points in this last section. My interpretation of
91 component based design is that we'll allow users to create their own
92 component (which uses a specific interface) and link those to the
93 program. Whether that linking happens at runtime or compile time is not
94 specified yet, but I wouldn't exclude one.
96 Examples of such components that were given in the past include a
97 'logging strategy', a 'compression strategy', a 'parallel compilation
98 strategy', an 'installation strategy', ... The bottleneck areas in
99 current portage. What we don't want portage-ng to be is one huge file
100 with over 10 thousand lines of code. 'Components' is a generic term
101 we've introduced and which includes 'patterns', 'objects', 'modules',
102 'tiers', 'layers', all concepts which facilitate parallel development,
103 community development without focusing explicitly on one paradigm.
105 Pieter
108 --
109 gentoo-portage-dev@g.o mailing list