I think the way you solved the problem of listing the supplemental modules in the {post,pre}rm scripts is the best one. I wouldn't worry too much about having to manually list the modules on d/rules; there are worse problems than that (for example, dynamically generating maintscripts... ugh).
As for your question about whether we should backup block-gluster.so. I tend to believe that if the user removes qemu-block-supplemental, they know what they're doing because they actively need to issue the removal command themselves. For that reason, I suggested that we should explicitly include the list of supplemental modules being shipped in the new binary package. I think it will make things clearer for the users.
Other than that, I really don't have much else to say. Your investigative work is amazing and I think you covered every corner case I could think of.
Thanks, Andreas.
I think the way you solved the problem of listing the supplemental modules in the {post,pre}rm scripts is the best one. I wouldn't worry too much about having to manually list the modules on d/rules; there are worse problems than that (for example, dynamically generating maintscripts... ugh).
As for your question about whether we should backup block-gluster.so. I tend to believe that if the user removes qemu-block- supplemental, they know what they're doing because they actively need to issue the removal command themselves. For that reason, I suggested that we should explicitly include the list of supplemental modules being shipped in the new binary package. I think it will make things clearer for the users.
Other than that, I really don't have much else to say. Your investigative work is amazing and I think you covered every corner case I could think of.
LGTM, +1.