Checking if another package is upgraded at the same time

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Checking if another package is upgraded at the same time

Kari Pahula-2
I'm maintaining two interrelated packages, crossfire-server and
crossfire-maps.  The former depends on the latter.  It is possible to
upgrade them separately, but upgrading the maps alone leads to
problems.  The server runs as a daemon and will be more or less at an
inconsistent state if the maps are upgraded while it is running.

Restarting the server needs to be done when upgrading crossfire-maps.
But having one package to automatically cause another to run
/etc/init.d/foo restart is certain to surprise a number of users.
Using debconf to ask whether to abort install, install and restart or
just install sounds like a good idea to me.

But doing this leads to another slight problem when upgrading
crossfire-server and crossfire-maps at the same time.  Namely, the
question in crossfire-maps is unnecessary in this case since upgrading
crossfire-server will restart the server anyway.  So I'd like to have
crossfire-maps to simply go ahead and install the files if the server
is upgraded on the same run.  Is there any reliable way to check if
the server is being upgraded in crossfire-maps' preinst?

Of course, the question is also unneeded when the server isn't running
or even installed at all.

signature.asc (198 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Checking if another package is upgraded at the same time

Justin T Pryzby-2
On Thu, Mar 23, 2006 at 12:11:59AM +0200, Kari Pahula wrote:
> I'm maintaining two interrelated packages, crossfire-server and
> crossfire-maps.  The former depends on the latter.  It is possible to
> upgrade them separately, but upgrading the maps alone leads to
> problems.  The server runs as a daemon and will be more or less at an
> inconsistent state if the maps are upgraded while it is running.
So you want to have a one-way dependency (since you can have -maps
installed without "causing problems").  -server should depend on
-maps, perhaps (>=X-1), (<<[X+1]-1).  The trailing -1 is the debian
version, not a subtraction, but the [X+1] is subtraction:

Depends: crossfire-maps (>=0.95.3), crossfire-maps (<<0.96)

This assumes that the 3rd version component is for bugfixes, and
doesn't break compatibility.

> Restarting the server needs to be done when upgrading crossfire-maps.
> But having one package to automatically cause another to run
> /etc/init.d/foo restart is certain to surprise a number of users.
> Using debconf to ask whether to abort install, install and restart or
> just install sounds like a good idea to me.
Overuse of debconf is discouraged; check the dict-bouvier and
gazetterer packages for examples one one package restarting another
packages daemon.

Note that policy 9.3.3.2 "strongly recommends" using invoke-rc.d (when
available) rather than running the init scripts directly.

> But doing this leads to another slight problem when upgrading
> crossfire-server and crossfire-maps at the same time.  Namely, the
> question in crossfire-maps is unnecessary in this case since upgrading
> crossfire-server will restart the server anyway.  So I'd like to have
> crossfire-maps to simply go ahead and install the files if the server
> is upgraded on the same run.  Is there any reliable way to check if
> the server is being upgraded in crossfire-maps' preinst?
I think this is probably one of the questions that is indicitive of
doing stuff the wrong way :)

Justin


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Checking if another package is upgraded at the same time

Kari Pahula-2
On Wed, Mar 22, 2006 at 06:08:13PM -0500, Justin Pryzby wrote:
> On Thu, Mar 23, 2006 at 12:11:59AM +0200, Kari Pahula wrote:
> > problems.  The server runs as a daemon and will be more or less at an
> > inconsistent state if the maps are upgraded while it is running.
> So you want to have a one-way dependency (since you can have -maps
> installed without "causing problems").  -server should depend on
> -maps, perhaps (>=X-1), (<<[X+1]-1).  The trailing -1 is the debian
> version, not a subtraction, but the [X+1] is subtraction:
>
> Depends: crossfire-maps (>=0.95.3), crossfire-maps (<<0.96)

The problem with this is that there's a second set of maps too,
crossfire-maps-small.

Other than that this is an ugly hack, since the dependency is not real
but only in there to cause server restarts.

> > Restarting the server needs to be done when upgrading crossfire-maps.
> > But having one package to automatically cause another to run
> > /etc/init.d/foo restart is certain to surprise a number of users.
> > Using debconf to ask whether to abort install, install and restart or
> > just install sounds like a good idea to me.
> Overuse of debconf is discouraged; check the dict-bouvier and
> gazetterer packages for examples one one package restarting another
> packages daemon.

Both of those restart the server silently.  Restarting
crossfire-server will cause any remote players to have their
connection abrubtly broken and to lose any progress that they've had
since their logon.  That's not quite what I'd call a smooth upgrade.
Is it reasonable to expect users to expect this behavior on upgrading
the maps?  Would it be enough to put in crossfire-maps description
that upgrading maps will cause the server to restart?

At least I think I can safely assume that users will know to expect
that upgrading the crossfire-server package itself to cause the server
to restart.

> > is upgraded on the same run.  Is there any reliable way to check if
> > the server is being upgraded in crossfire-maps' preinst?
> I think this is probably one of the questions that is indicitive of
> doing stuff the wrong way :)

I wish that there were some way to say that an another package has to
be fully installed before configuring a package, but only if that
another package is to be installed at all.  Pre-depends does half of
that, but I'd like to drop the depends-part of what it does.

Then I could simply check with netstat if clients are still connected
to the server and give the user options about what to do in that case,
instead of just silently restarting the server.  The chances are that
after a server restart any players haven't yet connected when the maps
are to be installed and I get away with not asking that question.

But even that might be a bit too complicated way to approach this.
Nothing's worse than software that tries to be too intelligent.

It seems to me that adding a warning to crossfire-maps' description
and then silently restarting server in its postinst might be the best
course of action.

signature.asc (198 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Checking if another package is upgraded at the same time

Bas Wijnen
On Thu, Mar 23, 2006 at 10:50:38AM +0200, Kari Pahula wrote:
> Restarting crossfire-server will cause any remote players to have their
> connection abrubtly broken and to lose any progress that they've had since
> their logon.  That's not quite what I'd call a smooth upgrade.

I don't know if you are upstream yourself, or if upstream is likely to accept
large patches from you, but there is a real solution to this problem.  I'd say
the problem really is that you cannot upgrade your maps without the players
being disconnected.

First of all, I point out that you will want the newly installed maps to be
usable, so not restarting the server because there are still players on it is
not acceptable.  There are some options to really solve this:
- If you can change the server so that it can use the new maps without a
  restart, that would obviously solve the problem.  You can either do this by
  always looking on disk, so the new maps are found when needed, or in the way
  inetd does it, by rereading config files at SIGHUP.
- You can also do it like ssh: every connection is forked off when
  established.  Then when the server restarts, the connections continue to
  exist.  If you need clients to talk to each other, then this is probably not
  an option.  It also won't work if existing clients need the new maps.
- The coolest approach IMO (but probably not the least error-prone) is to use
  execv's behaviour of keeping fd's open.  It is a huge security design bug
  that this is the default, but the possibility is nice. ;-)  What it means is
  that you can restart the server without losing your connections.  You need
  to tell the new executable about the open file descriptors (for example via
  some temporary file).  Then if started with a "use this temporary file for
  state" option, it reads the file descriptors from there and uses them.

> Is it reasonable to expect users to expect this behavior on upgrading the
> maps?

I don't think so, but it's acceptable if fixing it is not feasable.

> Would it be enough to put in crossfire-maps description that upgrading maps
> will cause the server to restart?

It depends on how you think the package will be used.  I think in most cases
it is better to do the restart, but perhaps you want to add a debconf low
priority question if the user really wants this.  Then the default is to
restart, and people running huge servers which want to keep their clients can
use dpkg-reconfigure and manually restart when it is appropriate for them.

> At least I think I can safely assume that users will know to expect
> that upgrading the crossfire-server package itself to cause the server
> to restart.

Yes, but even in that case it would be nice if the clients don't get
disconnected. ;-)

Thanks,
Bas

--
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc (198 bytes) Download Attachment