1 |
On Sat, 2003-11-29 at 07:34, Jason Stubbs wrote: |
2 |
> In light of the architectural requirements, I attempted to write functional |
3 |
> requirements that aren't tied to any other piece of functionality. While I |
4 |
> haven't stated it in the document, the intention is to make it easier to |
5 |
> descern points of separation of functional components when it comes time to |
6 |
> actually do the design - yeah I know, jumping the gun. |
7 |
> |
8 |
> Anyway, constructive comments are always appreciated. |
9 |
|
10 |
> Configure & compile sources |
11 |
> |
12 |
> Any and all available compilation options should be available to the |
13 |
> user. |
14 |
|
15 |
In this paragraph, there seem to be several points and I'm not sure I |
16 |
understand all of them. What is the purpose of having "Compilation |
17 |
options [...] remembered across compilations?" For what purpose? Can |
18 |
this purpose be expressed as a general requirement or design goal rather |
19 |
than a specific feature request? |
20 |
|
21 |
> ** General Package Management ** |
22 |
> |
23 |
> Querying available packages |
24 |
|
25 |
By "Querying", do you mean user queries, such as "emerge -s"? If so, |
26 |
this should be listed as a functional requirement for the default |
27 |
text-based user interface (which may end up being a component or |
28 |
plugin.) The requirements for the default text-based interface can be a |
29 |
subsection of the main spec document. This part should also be rewritten |
30 |
to be more specific about what you want, such as "Responses to user |
31 |
queries by the text-based interface should be able to display a |
32 |
comprehensive set of related metadata, beyond that which "emerge -s" |
33 |
currently displays, including..." |
34 |
|
35 |
> Install packages |
36 |
> |
37 |
> Packages should be installed by the same method whether using |
38 |
> precompiled packages or compiled sources. |
39 |
|
40 |
What do you mean by "method?" It sounds like you're refering to an |
41 |
interface issue rather than an internal architecture issue. |
42 |
|
43 |
> Upgrade packages |
44 |
> |
45 |
> When packages are upgraded, existing files should be backed so that |
46 |
> upgrades can be easily rolled back when necessary. |
47 |
|
48 |
Some people may not want to create back-ups for roll-backs. I think what |
49 |
is important is that the capability exists to write a portage-ng |
50 |
component to provide this functionality. This can be translated into a |
51 |
design goal: |
52 |
|
53 |
"The process of installing files to disk should be fully upgradable so |
54 |
that capabilities such as roll-backs of already-installed packages can |
55 |
be easily integrated into portage-ng." |
56 |
|
57 |
Or it could be added as a comment to the section talking about how |
58 |
portage-ng should be modular, to give more specific parameters about |
59 |
what this modularity should allow us to do. |
60 |
|
61 |
It can also be added as a functional requirement as well. I just want to |
62 |
look at ways to "expand on" the functionality we want and derive general |
63 |
architecture requirements and design goals from them. |
64 |
|
65 |
> Uninstalling installed packages |
66 |
> |
67 |
> Packages should be checked for reverse dependencies to ensure that |
68 |
> removal does not affect system functionality. |
69 |
|
70 |
I think this needs to be distilled too. In order to act on reverse |
71 |
dependencies, they need to be recorded. So we can break this down into a |
72 |
requirement: |
73 |
|
74 |
"All potentially-useful metadata should be recorded for each installed |
75 |
package, including items such as what specific versions of dependencies |
76 |
were installed at the time the package was compiled. This will allow for |
77 |
support of more advanced dependency algorithms, such as ones that handle |
78 |
reverse dependencies." |
79 |
|
80 |
and then add reverse deps as a functional requirement in its own |
81 |
section. |
82 |
|
83 |
I'll add your stuff to the doc for its next revision, and then get the |
84 |
XML online. |
85 |
|
86 |
Regards, |
87 |
|
88 |
Daniel |