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