From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8419 invoked by uid 1002); 30 Nov 2003 01:13: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 13685 invoked from network); 30 Nov 2003 01:13:42 -0000 X-WM-Posted-At: mailandnews.com; Sat, 29 Nov 03 20:13:42 -0500 From: Jason Stubbs To: gentoo-portage-dev@gentoo.org Date: Sun, 30 Nov 2003 10:13:37 +0900 User-Agent: KMail/1.5.93 References: <1070077621.17021.23.camel@ht.gentoo.org> <200311292334.30192.jasonbstubbs@mailandnews.com> <1070121755.17021.147.camel@ht.gentoo.org> In-Reply-To: <1070121755.17021.147.camel@ht.gentoo.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Message-Id: <200311301013.38194.jasonbstubbs@mailandnews.com> Subject: Re: [gentoo-portage-dev] Updated portage-ng requirements doc X-Archives-Salt: 6b462eaa-4927-4829-a817-db92173e902e X-Archives-Hash: 7061a351744bb44785b5cb025392ef7d On Sunday 30 November 2003 01:02, Daniel Robbins wrote: > 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? For "compilation option" read "USE flag". This is an instance where using terminology of the current implementation is actually clearer. Perhaps stating it as "per-package options should be supported" is much clearer? > > ** 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..." Actually, I was thinking more along the lines of "ebuilds" supporting variable amounts of information and that extra types of information should be able to be added without breaking other components, although I failed to state that at all. I also wanted to list minimally required information for a package, but now I realise that the only information an installed package needs to offer is what files are installed. > > 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. Yep, get rid of that. > > 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. I've never been good at this step in the process. I can easily recognise quality but have trouble producing it. My point is that I read the systemspec you wrote and couldn't think of anything that it didn't cover without thoughts of an actual design. A design entered my head here too! ;-) Like you've interpreted, my intention was to state that support for that functionality (even by extension or replacement) is required. > > 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 fail to see the difference between the two, but I'm sure that all will be made clear. > I'll add your stuff to the doc for its next revision, and then get the > XML online. Sounds good. Once there's an XML version online, it will seem more formal and thus a lot more input should be received. Thanks for your consideration. Regards, Jason Stubbs -- gentoo-portage-dev@gentoo.org mailing list