Hi, [email protected]: > I see an upstream PR of mine > (https://github.com/micahflee/torbrowser-launcher/pull/310) has been > applied to 0.2.9-2 but the recommendations included in there for > package maintainers were not followed (see e.g. commit d62a69).
I may have over-reacted, sorry. After being poked about this by Adrian Bunk I've re-read https://github.com/micahflee/torbrowser-launcher/pull/310/commits/d62a692a4a2a885d1410c0d931c08028a61fa246 and actually we're in that case: - if we don't unload the old profile from the kernel, surprising behaviour will happen such as: - any already running Tor Browser's Firefox executable will be left confined under the old profile which won't play well with new rules that have peer=torbrowser_firefox; - unpredictable behavior when a new Tor Browser is started, because two profiles matching the Tor Browser's Firefox executable are loaded. > Let's fix that before the package makes it into testing and > stretch-backports. I suggest adding a NEWS.Debian entry that strongly > recommends users to reboot their system after upgrading to >= 0.2.9-2~. Sadly very few users will see NEWS.Debian. We could also use the /var/run/reboot-required mechanism but reboot-notifier is not installed by default so most users won't see that either. > Ideally, a postinst snippet would detect whether we're upgrading to > a version >= 0.2.9-2~ for the first time and if so, display the same > recommendation (in a non-interactive way). But let's not block on > that :) Alternatively we could: if a Tor Browser managed by torbrowser-launcher is running: ask the user to close it and wait for it to happen (assuming it's OK to interactively prompt the user during upgrades) finally: unload the old profile This should fix the two failure modes I've described above. I'll let the active package maintainers make the call. I'm happy to provide more info if needed :) Cheers, -- intrigeri
