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

[Jason Stubbs <jasonbstubbs@mailandnews.com>]

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