>> Do you want to do the changes? I can also try to do it tomorrow if >> they aren't objections.
>I probably should merge (at least some of) the "study" and link count patches >first, as those change the landscape quite a bit. I'll try to do that as soon >as the caffeine kicks in for good. Sure, I will wait for changes. >On a somewhat related note, I'm pondering about changing fsm to do staged >removals too, ie rename before actually removing. It doesn't make much >difference as things are now, but I've also started seriously thinking about >changing the fsm to the model we discussed earlier where unpacking and >setting >permissions etc is first done for all files, and only if that >succeeds completely we actually commit to renaming them all to the final >target, and undo the whole lot if anything in unpacking failed. I think this would be the safest way not only from security, but also from correctness and also makes installation more robust in case of sudden power cuts and etc. >...which of course would actually fundamentally change the landscape >again: if commit is changed to consist only of renaming a file, then "commit" >hooks would no longer the right place to do security labeling etc. Argh! :) >In that model we'd be back to the "set metadata" hook, or actually two of >them to preserve the possibility of doing something after rpm did its own >business. >And in that model, both pre and post metadata hooks should get the >temp and final path as separate arguments. Yeah, but I guess maybe we can first finish with the current system and check that it works for whatever test cases we have (I can start using new hooks in msm plugin) and then change it when you move rpm to a new fsm model. I think this would be a big change for fsm, so won't be possible to do it fast anyway. Best Regards, Elena.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
