On Saturday 29 November 2003 13:28, Jason Stubbs wrote:
> On Saturday 29 November 2003 12:47, Daniel Robbins wrote:
> > Hi All,
> >
> > Attach is a much-improved portage-ng requirements doc (about 7x more
> > verbose than the previous one...)
>
> Would a list of required functionality (without any implementation details)
> be part of this document as well? It seems to me that such information
> would be useful at the commencement of the design phase.

I've taken the liberty of writing up all the requests for basic functionility 
that I can think of and put it into the attached file. I haven't completed 
the "enterprise/cluster management" section yet as it's far past bed-time. I 
ask that others can comment and expand/revise this document, after which it 
can enhance the brief second paragraph of Daniel's system-spec.

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.

Regards,
Jason Stubbs

** Ports **

Download sources or precompiled packages

Mirrors should be fully configurable - number, order, transport, credentials, etc. Furthermore, any package specific mirrors should also be fully configurable.


Configure & compile sources

Any and all available compilation options should be available to the user. Compilation options should be remembered across recompilations. Compilation options should be specified in such a way that commonality can be found between packages. Each package should provide definitions of common compilations options where there is any difference to the global interpretation. During compilation and preparation for installation, no files on the live filesystem should be affected.


** General Package Management **

Querying available packages

Queries should provide all information possible before a package is installed, including but not limited to:
- full title
- long description
- package home page
- size of minimally required source files or patches
- what packages are required to compile
- what packages are required to run
- license(s) for the package or parts there-in
- compilation flags known to fail


Query installed packages

Queries should cover all facets of installed packages, including but not limited to:
- what package provides which file
- the amount of disk space a package is occupying
- the date and time at which a package was installed


Install packages

Packages should be installed by the same method whether using precompiled packages or compiled sources. On installation, files should be noted for later removal. Under no circumstances should files on the live filesystem be overwritten by the installation of a package unless the files were provided by a previous version of the same package. In the case where another package "absorbs" the functionality of a package, it should be noted in the (partially-) depracated package.


Upgrade packages

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


Uninstalling installed packages

Packages should be checked for reverse dependencies to ensure that removal does not affect system functionality. Uninstalling packages should remove all files except those in protected directories. Files in protected directories should be backed up and removed from the live filesystem.


Updating available package database

As with mirrors above, the method of updating the package database should be fully configurable - number, order, transport, credentials, etc.


** Enterprise/Cluster Management **

Create precompiled packages
Provide package database mirror
Provide package source mirror
Provide precompiled package mirror

--
gentoo-portage-dev@g.o mailing list