Home / server / Questions / 206615
In Process
Arkaitz Jimenez
Asked: 2010-11-28 14:53:14 +0800 CST

Debian packaging, updates to a database

  • 772

I've a planned consecutive updates on a debian package I have for internal use on several servers.

Now, the updates have to happen one after each other at different times and some of the servers might jump several versions so updates can't be assumed to have happened for a given server.

So, I know the basics on debian packaging, but I might be skipping some advanced features that could help me here.
My only idea for now is to have a rather complex preinst and postinst scripts that entirely handle all the range of oldversion-newversion.

Any better idea?

debian database package-management update

1 Answers

  1. Speaking as a Debian Developer, generally you would only have one version of a package in an archive so having multiple versions that would have to be installed in sequence would not be an ideal or anything close to elegant solution. The pre- and post- install scripts can be used to automate some upgrade functionality but you would need to maintain those script closely between versions to have this properly work and could potentially cause problems if you attempted to remove or downgrade unless you did proper validation of the scripts.

    If you have changes that need to be maintained separately to ensure they get done in order you could use a master 'meta' package that could be installed and depends on the latest actual package. You'd then need to generate separate packages for each change and set the appropriate controls to ensure the proper order. This would require some good knowledge of the Debian Policy to accomplish, paying special attention to section 5.6.10 on package relationships as you'd need to Pre-Depend on the previous update packages.

    Separate packages may be more work but would allow you to do things incrementally, but the most ideal fashion would be having the package able to identify and make the necessary changes automatically. If config files aren't already using ucf this would be advisable as it would make managing them in the package easier if manual modifications/updates were performed later.

    Edit update:

    As I came back to re-read this after sleeping I noticed you were talking about a database being updated. In which case I think the packaging could be much more simple provided your database itself has some form of versioning schema and sequential updates are in separate files that need only be executed against the databases. Then it would only be a matter of adding a new file of commands to execute in an ordered fashion based on whatever version was stored in the database table. It is no longer necessarially a packaging issue as a database administration issue. All the package has to do is have proper pre- and post- scripts to check the existing database version and execute the necessary SQL command scripts in the package to bring it current.

    • 2