Re: [gentoo-portage-dev] Updated portage-ng requirements doc

[Daniel Robbins <drobbins@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3634 bytes --]

On Sat, 2003-11-29 at 07:34, Jason Stubbs wrote:
> In light of the architectural requirements, I attempted to write functional 
> requirements that aren't tied to any other piece of functionality. While I 
> haven't stated it in the document, the intention is to make it easier to 
> descern points of separation of functional components when it comes time to 
> actually do the design - yeah I know, jumping the gun.
> 
> Anyway, constructive comments are always appreciated.

> Configure & compile sources
>
> Any and all available compilation options should be available to the 
> user.

In this paragraph, there seem to be several points and I'm not sure I
understand all of them. What is the purpose of having "Compilation
options [...] remembered across compilations?" For what purpose? Can
this purpose be expressed as a general requirement or design goal rather
than a specific feature request?

> ** General Package Management **
> 
> Querying available packages

By "Querying", do you mean user queries, such as "emerge -s"? If so,
this should be listed as a functional requirement for the default
text-based user interface (which may end up being a component or
plugin.) The requirements for the default text-based interface can be a
subsection of the main spec document. This part should also be rewritten
to be more specific about what you want, such as "Responses to user
queries by the text-based interface should be able to display a
comprehensive set of related metadata, beyond that which "emerge -s"
currently displays, including..."

> Install packages
>
> Packages should be installed by the same method whether using 
> precompiled packages or compiled sources.

What do you mean by "method?" It sounds like you're refering to an
interface issue rather than an internal architecture issue.

> Upgrade packages
>
> When packages are upgraded, existing files should be backed so that 
> upgrades can be easily rolled back when necessary.

Some people may not want to create back-ups for roll-backs. I think what
is important is that the capability exists to write a portage-ng
component to provide this functionality. This can be translated into a
design goal:

"The process of installing files to disk should be fully upgradable so
that capabilities such as roll-backs of already-installed packages can
be easily integrated into portage-ng."

Or it could be added as a comment to the section talking about how
portage-ng should be modular, to give more specific parameters about
what this modularity should allow us to do.

It can also be added as a functional requirement as well. I just want to
look at ways to "expand on" the functionality we want and derive general
architecture requirements and design goals from them.

> Uninstalling installed packages
> 
> Packages should be checked for reverse dependencies to ensure that 
> removal does not affect system functionality.

I think this needs to be distilled too. In order to act on reverse
dependencies, they need to be recorded. So we can break this down into a
requirement:

"All potentially-useful metadata should be recorded for each installed
package, including items such as what specific versions of dependencies
were installed at the time the package was compiled. This will allow for
support of more advanced dependency algorithms, such as ones that handle
reverse dependencies." 

and then add reverse deps as a functional requirement in its own
section.

I'll add your stuff to the doc for its next revision, and then get the
XML online.

Regards,

Daniel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]