On 05/30/2014 04:29 PM, Kian-Tat Lim wrote: > Stop/start everything is not strictly necessary, but since you > build the entire system as one package, it's impossible to say what to > stop or start. As I recall, there are init.d scripts you could use to > stop/start only the things you are changing. Again, this is a > safety/convenience tradeoff. I don't think it's eups's responsiblity to care about the internals of a package. If you ask a package to "stop", the best thing for it is to stop everything that is started when you "start" the package. I think Jacek is just pointing out that he has a recipe to get things going, but his recipe says to do x, y, and z in sequence, to compile and get things installed. He doesn't need to do all of x, y, and z each time, so he'd like to invoke something more lightweight (that probably reuses some logic from x, y, or z). > If you built Qserv as a set of packages instead of as a single > package, it could be easier to manage this in a safe manner. True, but we have conceptually *one* system. It has distinct moving parts. This one system needs tools to integrate those parts more tightly and to manage their operation. And the management of those parts will be part of the system, though it is a part we have not really written yet. There should be qserv code that a dev can carefully invoke to restart certain bits. I don't think Jacek is asking to do what he wants through "eupspkg -er decl". It doesn't have to involve eups at all (though it might need to be eups-aware). We want to tighten the feedback loop of run-edit-compile-run. e.g., if I'm working on mysql, I don't really want to edit, rpmbuild -bb..., rpm -u .. (which might uninstall-install if update is unimplemented), recreate-testcase, run. I just want to edit, recompile, and re-run. -Daniel ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the QSERV-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1