On Wed, Nov 14, 2018 at 02:39:10AM -0500, Daniel Kahn Gillmor wrote:
> Some questions:
>
> * why put the module reloading in wireguard-tools.postinst and not in
> wireguard.postinst ? There's no guarantee that wireguard-dkms will
> have been upgraded by the time wireguard-tools.postinst gets invoked.
> Indeed, wireguard-tools only "Recommends: wireguard-dkms (=
> ${source:Version})", but doesn't "Depends: wireguard-dkms".
>
> In some sense, i think this might actually belong in the postinst of
> the wireguard metapackage, where we can be sure that both subpackages
> (the kernel parts and the userspace parts) have been installed. For
> minimalist installations (those without the wireguard metapackage)
> the admins can handle the upgrades manually themselves.
Now that you mentioned this, I am not so sure my assumption that
'postinst configure' of the recommended package must have been called
already when 'postinst configure' of the recommending one is called is
true, and a quick excursion into Policy, man deb-control and dpkg
sources did not convince me either way.
Maybe going with the meta package is a good idea then - especially since
it allows us a cheap 'opt-in' for the reloading behaviour.
>
> * The debconf question looks good (and thank you for taking the time to
> care for i18n!), but i'm wondering whether three values is too many
> to choose from. Is there any common use case where people would
> really need to have "always" instead of "module"?
I was thinking about changes to the wg-quick template unit (e.g., adding
more isolation features). But those are likely not as important as
changes to the module, so if we simplify to two (or no ;)) options, I'd
also go with the 'module' semantics.
> * heading further down the simplification path, what if we just said
> that the "wireguard" metapackage would take the behavior currently
> specified as "module" directly in it's postinst configuration,
> without offering the admin any choice? The admins who don't want
> that behavior can always choose to not install the "wireguard"`
> package, and can track the two sub-packages manually.
>
> I hope it's not too frustrating that i suggested the use of debconf over
> on the mailing list, and now i'm suggesting that maybe we don't need to
> use it at all. Seeing both eggie's work and your work on this has
> helped me think through the various options much farther than i would
> have gotten on my own.
If nothing else, I learned a thing or two about debconf last weekend :)
> If we end up with something even simpler, that might be even better!
>
> What do you think about this simplified proposal? To implement it, i'd
> probably change the description of the wireguard metapackage to clarify
> this new additional functionality, and then try to make a trimmed down
> version of your postinst script that does things as simply/quietly as
> possible.
Sounds good to me. And was so straightforward I just went ahead and
pushed that (the previous iteration is available as
mr/reload-on-upgrade_v1 tag). You probably still want to adapt the echo
statements and package description ;)
