On Thu, Nov 18, 2010 at 10:19:02PM -0500, Michael K. Johnson wrote:
> 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.
hmm, wouldn't the latter be preferable? are there technical reasons that
prevent the system-model from being a description of the end-state?
or are there other reasons that make the sequence of operations be a
better choice?
does this relate to the difference between install and update?
> 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)
> 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.
> 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?
> 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.
> 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.
greetings, martin.
--
cooperative communication with sTeam - caudium, pike, roxen and unix
searching contract jobs: debugging, programming, training and administration
--
pike programmer working in china community.gotpike.org
foresight developer (open-steam|caudium).org foresightlinux.org
unix sysadmin iaeste.at realss.com
Martin Bähr http://www.iaeste.at/~mbaehr/ is.schon.org
_______________________________________________
Foresight-devel mailing list
Foresight-devel@lists.rpath.org
http://lists.rpath.org/mailman/listinfo/foresight-devel
