From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3160 invoked by uid 1002); 29 Nov 2003 16:01:37 -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 2111 invoked from network); 29 Nov 2003 16:01:37 -0000 From: Daniel Robbins To: gentoo-portage-dev@gentoo.org In-Reply-To: <200311292334.30192.jasonbstubbs@mailandnews.com> References: <1070077621.17021.23.camel@ht.gentoo.org> <200311291328.50603.jasonbstubbs@mailandnews.com> <200311292334.30192.jasonbstubbs@mailandnews.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-4lG/aPlEyAYm7qzFyAQM" Organization: Gentoo Technologies, Inc. Message-Id: <1070121755.17021.147.camel@ht.gentoo.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sat, 29 Nov 2003 09:02:35 -0700 Subject: Re: [gentoo-portage-dev] Updated portage-ng requirements doc X-Archives-Salt: af1ea3c4-bae5-4d20-b293-3981c0183b18 X-Archives-Hash: 45535f071f3173d785c8e684d37b8510 --=-4lG/aPlEyAYm7qzFyAQM Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2003-11-29 at 07:34, Jason Stubbs wrote: > In light of the architectural requirements, I attempted to write function= al=20 > requirements that aren't tied to any other piece of functionality. While = I=20 > haven't stated it in the document, the intention is to make it easier to=20 > descern points of separation of functional components when it comes time = to=20 > actually do the design - yeah I know, jumping the gun. >=20 > Anyway, constructive comments are always appreciated. > Configure & compile sources > > Any and all available compilation options should be available to the=20 > 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 ** >=20 > 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=20 > 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=20 > 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 >=20 > Packages should be checked for reverse dependencies to ensure that=20 > 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."=20 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 --=-4lG/aPlEyAYm7qzFyAQM Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQA/yMMbffezrJ9WV/IRAii0AKCU6EWOHAiHsPGvOWq9ExArDzNwdQCeKjnW 7H1VyW4oer87z4mkLfmOFvE= =8WCb -----END PGP SIGNATURE----- --=-4lG/aPlEyAYm7qzFyAQM--