On Fri, Nov 19, 2010 at 03:44:52AM +0100, Martin Bähr wrote:
> seperate lines are ok too?
> update exif=contrib.rpath....@rpl:2/0.6.9-7-0.1
> update exiftags=contrib.rpath....@rpl:2/1.01-2-0.1
> update jhead=contrib.rpath....@rpl:2/2.8-1-0.1
>
> i think it makes the file more readable to only keep one trove per line,
> otherwise one might as well pack the whole model into one line.
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. For install
lines, we can aggressively parallelize due to invariants inherent
in the specification of install. For update lines, the behavior
of which is explicitly relative to the previous state, it is not
so cheap.
So, when *you* know that it doesn't matter semantically if you
provide multiple packages on a single update line, that update
line will run faster than multiple update lines because you are
very simply asking conary to do less work.
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
That command would then be expanded to the system-model line I
presented in my previous email (obviously, using whatever versions
are latest at the time that you run the command).
If you'd like a visual expression of what things work in parallel,
use the --model-graph option:
conary sync --model-graph=/tmp/g.dot
dot -Tsvg /tmp/g.dot > /tmp/g.svg
eog /tmp/g.svg
The numbers in the graph represent line numbers in the
/etc/conary/system-model file. In many cases, there will be
additional data; each trove mentioned in the file is looked up in a
separate operation, and so not only the line number but the trove
specification is included. Unfortunately, this graph can be huge
and you may need to scroll around in it.
> this is not equivalent to the conary pin; command?
Nope! :)
It is certainly similar in effect, for explicitly listed troves.
However, it's not as simple to map as you might think. Think of
the kernel -- pinned explicitly by default configuration, unlikely
to be listed in your /etc/conary/system-model file. And 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.
_______________________________________________
Foresight-devel mailing list
Foresight-devel@lists.rpath.org
http://lists.rpath.org/mailman/listinfo/foresight-devel
