On Fri, Oct 15, 2010 at 03:23:27AM +0200, Martin Bähr wrote: > On Thu, Oct 14, 2010 at 12:31:02PM -0400, Michael K. Johnson wrote: > > You can use vi to edit this file, and then run the "conary sync" > > command to apply the system model to your system. > > can i use emacs too? ;-)
No, only vi adds the special magic DWIM instructions! ;) > > You can construct one by hand, if you like, by looking at the output > > of the "conary updateall --items" to show you things you added that > > are not part of groups. However, that won't show you things that are > > in the groups but not installed by default. > > true, but if you know what you installed by hand, then everything you > don't recognize came as adependency. The problem is the other way around -- you may have run "conary update foo" and foo is in the groups by byDefault False, and "conary update foo" caused it to be installed on your system, but it does NOT show up in the output of "conary updateall items". > can the debug output be saved to a file? for people who are behind a > firewall that doesn't allow outgoing smtp connections? Well, the stuff that is sent is the manifest (you have it in the /var/lib/conarydb/manifest file) and the model. (It will also be the list of things that don't apply, but that's a duplicate for our convenience of the copy that is included in comments in the model). So it's all there -- the email to us is so we can have a variety of real-life models from the genmodel tool, and sending them from this tool means that the mailbox in which they are stored is consistent enough that I could trivially parse the whole thing automatically. > > $ sudo conary update > > conary=foresight.rpath....@fl:2-devel/2.2.alpha_d8cd5cea61d1-1-1 > > ah, why was it necesary to change the behaviour of conary update? > can the conary update not continue to search for the latest version of > the requested trove? That's the whole point of having a search path: to find things on it and keep consistent sets by default. You'll get the latest thing when you search off the path. > i thought it would be enough to have the new conary install command > behave like in your example. If you have a system model, it will always work by constructing the set of troves that should be on your system and then moving your system to that set of troves. We can't reasonably have some conary system manipulation honor the system model and some ignore it. Therefore, if you have a system model, commands that don't make sense for a system model aren't allowed. > conary-2.2 is not released yet, so there is still time to change how > conary update works. Yes, there is. But we won't make it ignore the system model if you have a system model. 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. Whatever we implement for update -- or for any other verb, if we decide that it makes sense to add another verb -- it still has to be something that makes sense in the context of the model. It's not really "make the update command do <foo>", it's "make the update statement in the system model do <foo>" -- anything you can do with a conary command to the model, you can do by editing the system model with a text editor and applying the model to the system with "conary sync". We really want the default command line to keep things pretty thoroughly in sync as we map the existing command line to the system model -- avoiding the kinds of problems we've had with dependency zombies from the updateall model. That's why update is specified the way it is. However, if you see this as a real problem, then we need to talk about the big picture -- what you are trying to accomplish, how you want to define your system in general. I'd hate, for example, to provide another verb and then find out that it doesn't really solve your problem... Thanks! _______________________________________________ Foresight-devel mailing list Foresight-devel@lists.rpath.org http://lists.rpath.org/mailman/listinfo/foresight-devel
