On Fri, Oct 15, 2010 at 05:57:39AM +0200, Martin Baehr wrote: > i guess, what i don't understand is, why does bypassing the search path > imply bypassing the system model?
I misunderstood you to have been saying that you wanted conary update to bypass the system model while install used the system model. Sorry for the misunderstanding. update and install are both system model commands with different semantics. Both honor the search path; both can affect the search path for following commands; the difference is in which troves will be installed by default. Having a way to explicitly ignore the search path for one command would have to be a different verb, for the technical reason that we have defined the modeling language such that verbs do not take modifiers, only objects. > does that mean that > conary update conary=foresight.rpath....@fl:2-devel/2.2.alpha_d8cd5cea61d1-1-1 > > is bypassing the system model too? Well, if that version is on the search path, the search path would be used to choose the flavor; if not, it will use the system flavor. > > Again, using a system model is a lot like building a group for your > > system. In a group, if you want a trove that is not found via your > > search path, you have to be quite explicit about it. This is > > bringing this semantic to the command line. > > ok, i am trying to test that right now. > one point i hope to find is that conary gives feedback explaining why > there is nothing to update. That's a flaw, I think. We haven't wired things up enough to recognize lines which are no-ops. I could see something like: warning: "update conary" (line 7) had no effect However, it's harder to try to come up with a way to explain the reason in a more helpful way since it basically always means "the impact of this operation was already represented at this point in the system model" which is a very wordy thing to say... We've thought of allowing some operation, perhaps automatically, perhaps run by a command like "conary simplifymodel" that would execute the model and remove pieces that are (at that moment in time!) no-ops. That would require mostly the same wiring that would be required by that error message. > ah, ok, now that is the answer i am looking for. old conary update > caused to many problems and you want to get rid of it. of course then my > suggestion makes no sense. i was just trying figure out why the old > semantics of 'conary update' had to be changed. I guess I wrote my answer backward. :) > from a developers perspective, what i sometimes want to do is to test > the latest version of a package even if it is not yet in the group, or > worse, pick the package from a different label. but being explicit about > that should work for me. > > however in some cases i want to pick an explicit version only once, i > never want to upgrade that version unless my searchpath has a newer one. > this is for cases where foo is broken, and a fix is in 2-devel but not > yet ready for stable, but the fix is urgently needed, then i can pick > that fix as a onetime workaround, and as soon as stable has caught up > the workaround will disappear. > > i don't know if that can be achived somehow. (this might need a new verb > or at least some special option: updateonce or pintosearchpath (means: > even though this trove comes from label 2-devel updates afterwards > should really only come from the searchpath) Thank you! Use cases like this really help. I don't know what the right way to handle this use case is. One idea would be if we had an "updatelatest" verb, which "conary updateall" would either remove entirely or change to an update or install operation. I'd like to discuss this use case with Erik when he returns next week, because I don't have an obvious answer to give. My answer previously was very developer-centric -- I thought that the pattern was installing a locally-built .ccs file for testing, and then rolling back and updating after groups were built. While I think that pattern exists, I was perhaps wrong in thinking it dominant. Therefore, we need to have a usable way of handling this use case. > lastly, while on the topic: > > is the following problem solved? > $ foo; > command not found > $ sudo conary update foo > foo is uptodate > $ conary q foo: > foo:lib > $ sudo conary sync foo > (installs :devel, :devellib and other stuff i don't want) > > the expected solution is that: > 'conary install foo' will always install :runtime and related troves > regardless of wheter foo:lib is already there or not. Yes, exactly. That is why we have install. And, in fact, that's why I documented that for system model you normally want "install", not "update": $ sudo conary install foo should do what you want. Also, in system model, "conary install" makes for models that run faster than "conary update" :) Update is really for handling corner cases. _______________________________________________ Foresight-devel mailing list Foresight-devel@lists.rpath.org http://lists.rpath.org/mailman/listinfo/foresight-devel
