Sven Hartge wrote:
> I'm not totally sure, if this is a possible bug, but because the
> postinst of bacula-director-sqlite3 uses sqlite to dump the old bacula-2
> database it should depend on sqlite _and_ sqlite3 (as long as the
> upgrade code is inside the postinst), since it may be possible to end up
> in a situation where sqlite is already removed when the postinst trying
> to use it is run by dpkg.
I suppose it is theoetically possible that a dist-upgrade could have
something that conflicts: on sqlite, but it seems unlikely for the
squeeze release since they've coexisted so long.
Also, note:
Package: bacula-director-sqlite
Depends: bacula-director-sqlite3 (>= ${binary:Version}), sqlite3,
sqlite2, ${shlibs:Depends}
Architecture: all
Description: network backup, recovery and verification - SQLite 2
director transition
This package exists to upload pre-3.0 Bacula SQLite v2 installations to
SQLite v3 with Bacula 3.0. The SQLite v2 support has been deprecated
in Bacula 3.0, and this package will get you migrated to Bacula 3.0.
.
Once you are successfully migrated, you can safely delete this package.
.
This package does nothing for people that aren't upgrading.
So I do make an effort to ensure that people upgrading will still have
sqlite2 on their systems. Of course, it's not a 100% guarantee as a
dist-upgrade could remove this too, but don't you think it's pretty good
at least?
-- John
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
