Brian Harring posted on Wed, 14 Apr 2010 11:10:29 -0700 as excerpted: >> The next thing is aborting merges. When running multiple emerges, >> aborting one of them is as simple as pressing ^c. With daemon, we would >> have to implement an ability of aborting/removing packages in runtime >> -- and that would be another example of dependency tree mangling. > > Aborting merges is a very, very bad idea. Consider a pkg that has > dlopen'd plugins, and just went through an ABI change for that > interface. If you interupt that merge it's entirely possible you'll get > just the lib merged (meaning a segfault on loadup of the plugins), or > vice versa (old lib is still in place, but new plugins are there). > > Don't abort merges- that really should be effectively an atomic OP, not > interuptible.
Umm... I think you two are using the same words for different things. Definitely, aborting qmerge (transfer to the live filesystem) isn't a good idea, but in context, it's plain that MG's talking about the entire merge process, from setup, unpack and prepare thru qmerge and postinst (which is how the terms are used in the ebuild qmerge vs. ebuild merge context as well). Clearly the entire merge doesn't need to be atomic, or we'd not be talking about parallel merges in the first place, nor would we have available all the individual ebuild <command> substeps. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
