1 |
On Sunday 30 November 2003 01:02, Daniel Robbins wrote: |
2 |
> On Sat, 2003-11-29 at 07:34, Jason Stubbs wrote: |
3 |
> > In light of the architectural requirements, I attempted to write |
4 |
> > functional requirements that aren't tied to any other piece of |
5 |
> > functionality. While I haven't stated it in the document, the intention |
6 |
> > is to make it easier to descern points of separation of functional |
7 |
> > components when it comes time to actually do the design - yeah I know, |
8 |
> > jumping the gun. |
9 |
> > |
10 |
> > Anyway, constructive comments are always appreciated. |
11 |
> > |
12 |
> > Configure & compile sources |
13 |
> > |
14 |
> > Any and all available compilation options should be available to the |
15 |
> > user. |
16 |
> |
17 |
> In this paragraph, there seem to be several points and I'm not sure I |
18 |
> understand all of them. What is the purpose of having "Compilation |
19 |
> options [...] remembered across compilations?" For what purpose? Can |
20 |
> this purpose be expressed as a general requirement or design goal rather |
21 |
> than a specific feature request? |
22 |
|
23 |
For "compilation option" read "USE flag". This is an instance where using |
24 |
terminology of the current implementation is actually clearer. Perhaps |
25 |
stating it as "per-package options should be supported" is much clearer? |
26 |
|
27 |
> > ** General Package Management ** |
28 |
> > |
29 |
> > Querying available packages |
30 |
> |
31 |
> By "Querying", do you mean user queries, such as "emerge -s"? If so, |
32 |
> this should be listed as a functional requirement for the default |
33 |
> text-based user interface (which may end up being a component or |
34 |
> plugin.) The requirements for the default text-based interface can be a |
35 |
> subsection of the main spec document. This part should also be rewritten |
36 |
> to be more specific about what you want, such as "Responses to user |
37 |
> queries by the text-based interface should be able to display a |
38 |
> comprehensive set of related metadata, beyond that which "emerge -s" |
39 |
> currently displays, including..." |
40 |
|
41 |
Actually, I was thinking more along the lines of "ebuilds" supporting variable |
42 |
amounts of information and that extra types of information should be able to |
43 |
be added without breaking other components, although I failed to state that |
44 |
at all. I also wanted to list minimally required information for a package, |
45 |
but now I realise that the only information an installed package needs to |
46 |
offer is what files are installed. |
47 |
|
48 |
> > Install packages |
49 |
> > |
50 |
> > Packages should be installed by the same method whether using |
51 |
> > precompiled packages or compiled sources. |
52 |
> |
53 |
> What do you mean by "method?" It sounds like you're refering to an |
54 |
> interface issue rather than an internal architecture issue. |
55 |
|
56 |
Yep, get rid of that. |
57 |
|
58 |
> > Upgrade packages |
59 |
> > |
60 |
> > When packages are upgraded, existing files should be backed so that |
61 |
> > upgrades can be easily rolled back when necessary. |
62 |
> |
63 |
> Some people may not want to create back-ups for roll-backs. I think what |
64 |
> is important is that the capability exists to write a portage-ng |
65 |
> component to provide this functionality. This can be translated into a |
66 |
> design goal: |
67 |
> |
68 |
> "The process of installing files to disk should be fully upgradable so |
69 |
> that capabilities such as roll-backs of already-installed packages can |
70 |
> be easily integrated into portage-ng." |
71 |
> |
72 |
> Or it could be added as a comment to the section talking about how |
73 |
> portage-ng should be modular, to give more specific parameters about |
74 |
> what this modularity should allow us to do. |
75 |
> |
76 |
> It can also be added as a functional requirement as well. I just want to |
77 |
> look at ways to "expand on" the functionality we want and derive general |
78 |
> architecture requirements and design goals from them. |
79 |
|
80 |
I've never been good at this step in the process. I can easily recognise |
81 |
quality but have trouble producing it. My point is that I read the systemspec |
82 |
you wrote and couldn't think of anything that it didn't cover without |
83 |
thoughts of an actual design. A design entered my head here too! ;-) Like |
84 |
you've interpreted, my intention was to state that support for that |
85 |
functionality (even by extension or replacement) is required. |
86 |
|
87 |
> > Uninstalling installed packages |
88 |
> > |
89 |
> > Packages should be checked for reverse dependencies to ensure that |
90 |
> > removal does not affect system functionality. |
91 |
> |
92 |
> I think this needs to be distilled too. In order to act on reverse |
93 |
> dependencies, they need to be recorded. So we can break this down into a |
94 |
> requirement: |
95 |
> |
96 |
> "All potentially-useful metadata should be recorded for each installed |
97 |
> package, including items such as what specific versions of dependencies |
98 |
> were installed at the time the package was compiled. This will allow for |
99 |
> support of more advanced dependency algorithms, such as ones that handle |
100 |
> reverse dependencies." |
101 |
> |
102 |
> and then add reverse deps as a functional requirement in its own |
103 |
> section. |
104 |
|
105 |
I fail to see the difference between the two, but I'm sure that all will be |
106 |
made clear. |
107 |
|
108 |
> I'll add your stuff to the doc for its next revision, and then get the |
109 |
> XML online. |
110 |
|
111 |
Sounds good. Once there's an XML version online, it will seem more formal and |
112 |
thus a lot more input should be received. Thanks for your consideration. |
113 |
|
114 |
Regards, |
115 |
Jason Stubbs |
116 |
|
117 |
-- |
118 |
gentoo-portage-dev@g.o mailing list |