On Fri, Nov 19, 2010 at 05:20:06AM +0100, Martin Baehr wrote:
> On Thu, Nov 18, 2010 at 10:19:02PM -0500, Michael K. Johnson wrote:
> > Each line manipulates the overall state relative to the state in
> > the previous line. This is an ordered list of operations, not an
> > unordered set of statements about desired end state.
>
> hmm, wouldn't the latter be preferable? are there technical reasons that
> prevent the system-model from being a description of the end-state?
Yes. That's called the "old update model", and it's what we are
trying to fix in the first place.
I don't mean to be a RTFM person, but I do want to make the man page
useful for this. Therefore, could you please re-read the man page
description of system model updates, so that we can have this discussion
in the context of improving the man page description of how system model
updates work? I *know* the man page isn't good enough, and I'd like
to make it better.
> or are there other reasons that make the sequence of operations be a
> better choice?
It's a representation of the semantics of how the system was constructed.
> does this relate to the difference between install and update?
Absolutely.
> > For install lines, we can aggressively parallelize due to invariants
> > inherent in the specification of install.
>
> so if i don't use update lines my system-model becomes pretty much an
> unordered set of statements. (except for search lines affecting the
> install lines)
Mostly.
> > For update lines, the behavior of which is explicitly relative to the
> > previous state, it is not so cheap.
>
> why would i want to use update in a system model?
> i would have thought that with the introduction of install, update would
> only be needed for cases where i want to change the versions of already
> installed troves without adding any new troves.
Bingo! "already installed troves" are defined, for the update operation
*relative to the actions done by the previous lines in the model*.
For the purposes of deciding what software should be installed on the
system, the system model code does not start with the current contents
of the system database. The system database is used:
* To look up information on troves
* After deciding what should be installed on the system, to determine
what changes need to be applied to the system to bring it into that
state.
> > So, when *you* know that it doesn't matter semantically if you
> > provide multiple packages on a single update line
>
> what would be a case where it does matter?
When there's potential trove content overlap, at least.
I'm not saying that there is no potential for optimization here.
However, it's not the optimization we're going to be working on
right now.
> > In the specific example I gave, my idea was that those three
> > packages are conceptually related. It's extremely feasible that
> > you might run the command:
> > conary update {exif{,tags},jhead}=contrib.rpath....@rpl:2
>
> but if the packages are completely unrelated it is even more feasable to
> update them all at the same time because they are unlikely to have
> conflicting dependencies. it is more likely that the order matters for
> packages which depend on each other, that is for packages which are
> related to each other.
The model represents operations taken to get the system into the
state it is currently in. You can edit the model to give it a
different history; doing so represents that you are making the
assertion that it's sufficiently similar in intent that you do
not care about any differences.
> > having "conary pin" do different things depending on whether a
> > matching trove can be found listed explicitly in the system-model file
> > is too confusing.
>
> if the trove is not listed then it could be added to the list.
> if i want to use the system-model to replicate a systems state on
> another machine, then the pin state may be part of that state that i
> want to copy.
The normal and intended use of "conary pin" is only for things
like the kernel, as a backup that is not an important part of the
definition of the system; it's an escape hatch to keep working
systems working in the face of reality.
If you have a case where the pinned trove is important to the state
of the system, then put an explicit entry into the model. That's
what we added that for.
_______________________________________________
Foresight-devel mailing list
Foresight-devel@lists.rpath.org
http://lists.rpath.org/mailman/listinfo/foresight-devel
