On Tue, Nov 30, 2010 at 04:13:59AM +0100, Martin Baehr wrote:
> On Mon, Nov 22, 2010 at 07:50:51PM -0500, Michael K. Johnson wrote:
> > I tried in 2.2.0 beta to improve the man page descriptions of system
> > model update operations. Let me know if it's still confusing;
>
> not as far as i can tell now.
> the only nitpick i have is that the description of the system-model file
> talks about the set of to-be-installed troves as "installed set".
> but "installed set" makes me think of the troves that are already
> installed. maybe a grammar issue, or a limitation in my english
> understanding.
Well, the "installed set" is jargon; we have to call that set
something. The "installed set" are the packages that would be
installed if the model ended there. Calling them the "would be
installed if the model ended here set" would be verbose... :)
But I'll re-read the man page and see if I can make that easier
to follow.
> "To make Conary not update a version when you use the conary updateall
> command, double the appropriate = in the system-model file."
>
> sounds complicated andeasy to missunderstand, also, what if there is no
> version in the file? maybe instead: "use == and the version"
I agree, that's poorly written. Thanks.
> this brings me back to the discussion about the difference to conary
> pin. i still think that they should be the same and pinned troves should
> be added to the system-model. if only to simplify things for the user.
I guess we'll have to disagree here. I don't think it will simplify
anything for the user. In normal use, it would cause people to get
older kernels installed if they sync to a model from another machine,
and the most recently-installed kernel on that system will become the
default kernel, which is not what they want. It would break things
in ways that we don't have a way to model the fix.
Automatic pinning is intended to solve an entirely disjoint type of
issue from explicitly-pinned troves in the system model.
> i believe that for simplicity and consistency of the interface normal
> operations on the system-model should be doable through conary commands.
Explicit pinning in the model is considered an advanced feature. It
is unlikely to be required in normal use.
> the handling of versions and == should also be explained a bit further
> down where the individual commands for the system-model are explained.
Can you be more precise here about which section(s) need "=="
to be further explained?
> what is the difference between troveSpec and troveSpec+?
We are using the using the extended regexp meaning of "+" (as used
consistently elsewhere there) of "one or more". So "troveSpec" means
one trove specification ("name=version[flavor]" where some parts may
be incompletely specified or entirely missing) and "troveSpec+" means
one or more troveSpec.
_______________________________________________
Foresight-devel mailing list
Foresight-devel@lists.rpath.org
http://lists.rpath.org/mailman/listinfo/foresight-devel
