From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19820 invoked by uid 1002); 29 Nov 2003 14:34:43 -0000 Mailing-List: contact gentoo-portage-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail Reply-To: gentoo-portage-dev@gentoo.org X-BeenThere: gentoo-portage-dev@gentoo.org Received: (qmail 13134 invoked from network); 29 Nov 2003 14:34:43 -0000 X-WM-Posted-At: mailandnews.com; Sat, 29 Nov 03 09:34:42 -0500 From: Jason Stubbs To: gentoo-portage-dev@gentoo.org Date: Sat, 29 Nov 2003 23:34:30 +0900 User-Agent: KMail/1.5.93 References: <1070077621.17021.23.camel@ht.gentoo.org> <200311291328.50603.jasonbstubbs@mailandnews.com> In-Reply-To: <200311291328.50603.jasonbstubbs@mailandnews.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_25Ky/KC9Gqf+M1S" Message-Id: <200311292334.30192.jasonbstubbs@mailandnews.com> Subject: Re: [gentoo-portage-dev] Updated portage-ng requirements doc X-Archives-Salt: d1fee35c-7ae5-4235-9949-963dc36a493b X-Archives-Hash: 6435c5195642d2e3492a21084b0a296d --Boundary-00=_25Ky/KC9Gqf+M1S Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 --Boundary-00=_25Ky/KC9Gqf+M1S Content-Type: text/plain; charset="iso-2022-jp"; name="portage-functional-reqs" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="portage-functional-reqs" ** 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 --Boundary-00=_25Ky/KC9Gqf+M1S Content-Type: text/plain; charset=us-ascii -- gentoo-portage-dev@gentoo.org mailing list --Boundary-00=_25Ky/KC9Gqf+M1S--