On Thu, Oct 14, 2010 at 10:43:02PM -0400, Michael K. Johnson wrote: > 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.
of course, just suggesting, that the email could be dumped into a file if sending fails, with the instruction to email this file. none of my machines have the capability to send mail out, and i have no desire to change that. > > 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. that is not what i meant. of course conary update should change the system model only. but it could change it in a way that is consistent with the current behaviour. (but i now understand why that is not desirable, see below) the old 'conary update' gets the latest version from the label. the new 'conary update' gets it from the search path. i guess, what i don't understand is, why does bypassing the search path imply bypassing the system model? does that mean that conary update conary=foresight.rpath....@fl:2-devel/2.2.alpha_d8cd5cea61d1-1-1 is bypassing the system model too? > we won't make it ignore the system model if you have a system model. just to be sure, i never meant to suggest that the system-model should be ignored. that makes no sense, of course. > 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. > 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. of course, i am not looking for yet another verb (install is already the new verb that i have been waiting for for a long time, i am exited to see it become a reality now) > 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. 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. > 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... the problem i wanted to solve is user expectation: conary update does not do anymore what it did before. but as you say, we want users to stop doing that kind of thing, so there is no way around disappointing a few of them. 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) 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. 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
