non-atomic upgrade

[eyequeue]

It seems desirable for firestarter to upgrade in a more atomic manner.

To illustrate, here is an excerpt of a recent upgrade run on dapper:

===snip===
Preparing to replace firestarter 1.0.3-1.1ubuntu1 (using .../firestarter_1.0.3-1.1ubuntu2_i386.deb) ...
Stopping the Firestarter firewall:done.
Unpacking replacement firestarter ...
Preparing to replace gcc-4.0-doc 4.0.3-1ubuntu3 (using .../gcc-4.0-doc_4.0.3-1ubuntu4_all.deb) ...
Unpacking replacement gcc-4.0-doc ...
Preparing to replace gnome-app-install 0.1.23 (using .../gnome-app-install_0.1.26_all.deb) ...
Unpacking replacement gnome-app-install ...
Setting up libmudflap0 (4.0.3-1ubuntu4) ...

Setting up cpp-4.0 (4.0.3-1ubuntu4) ...
Setting up gcc-4.0 (4.0.3-1ubuntu4) ...
Setting up libmudflap0-dev (4.0.3-1ubuntu4) ...
Setting up app-install-data (0.1.26) ...
Setting up cpp-4.0-doc (4.0.3-1ubuntu4) ...

Setting up firestarter (1.0.3-1.1ubuntu2) ...
Starting the Firestarter firewall: done.
===snip===

As you can see, the stopping of the firewall (in the pre-rm?) can be separated from the starting of the firewall (in the post-inst?) by a significant delay, if there are a number of packages to be upgraded.

The above was during a relatively-frequent dapper upgrade, but I'm thinking more of the much-longer upgrades, such as the breezy=>dapper dist-upgrade, for example.

Is there a plausible manner to change "invoke-rc.d firestarter stop" to "invoke-rc.d firestarter restart" or something similar, and still accomplish what you need during upgrade? I've seen that some packages appear to issue two "restart"s rather than a "stop" and subsequent "start", but never questioned the rationale (or mechanism).

The goal of course would be to limit the users' exposure to running without an active firewall, especially on machines where the admin doing the upgrade is not the sole active user. (ie, remote upgrades)

[Dennis Kaarsemaker (dennis)]

This would (afaik) need a change in apt. Currently the way upgrades are
done is (roughly):

1) prerm lots of existing packages
2) unpack lots of newpackages
3) postinst lots of newpackages

The reason is that this is much faster than doing this dance for each
package in a row.

For firestarter (and I can imagine other packages) this is less than
optimal, but I'm not sure how this can be changed properly.

 subscribe <email address hidden>

Scott, dpkg master, is this correct or am I talking rubbish?

[Scott James Remnant (Canonical) (canonical-scott)]

Actually, this is a firestarter bug; there's no reason it needs to stop itself in the maintainer script on upgrade -- it could just restart itself in the postinst.

prerm is told that it's being upgraded, not removed ("prerm upgrade <new-version>" rather than "prerm remove")

I assume it's doing that because it uses the old s-s-d --exec option that cares about the exact binary rather than just the filename

[William Grant (wgrant)]

Fixed in Feisty and Gutsy.