Package: bacula-director-sqlite3
Version: 5.0.2-2
Severity: wishlist
Tags: squeeze
The "Depends:" list of bacula-director-sqlite3 contains both sqlite3 and old
sqlite package, what leads to installing the significantly unnecessary package.
I've made a deeper investigation and noticed that a similar bug with the
similar reason was opened as Bug #599148 ("bacula-director-sqlite3 should not
depend on old sqlite") but then closed due to it introduced a new Bug #542825
("uses sqlite in postinst, but does not depend on sqlite"). I have suspicion
that the resolution of these problems was not the most convenient for the users.
My understanding of the problem:
#599148/this bug: when you install the bacula-director-sqlite3 package to use
the shiny new glossy modern sqlite3 as a backend, you end up with both sqlite3
and old boring sqlite packages installed, even if you most likely will never
use sqlite package. Why?
Because, if you don't install sqlite, then, due to #542825, there *may happen*
that you've had the sqlite2-based backend installed before, and now you won't
be able to upgrade it to sqlite3 using dist-upgrade or something.
The current resolution of the problem is to install both sqlite3 and sqlite, to
resolve the problems of the people who are using dist-upgrade but make some
problems to the people who are doing the fresh install. But what if the sqlite
package is added to some other kind of dependency?
Let's read the http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html#s-depends:
"Package A depends on Package B if B absolutely must be installed in order to
run A" - it seems that neither "absolutely" nor "must" words do reflect the
proper relation between sqlite and bacula-director-sqlite3.
"Package A recommends Package B, if the package maintainer judges that most
users would not want A without also having the functionality provided by B" -
it's the decision of the package maintainer, but I won't be that *most* users
of bacula-director-sqlite3 would want sqlite installed. Though that's a good
first option, as it still allows to remove sqlite as soon as you definitely
know you don't need it.
'Package A suggests Package B if B contains files that are related to (and
usually enhance) the functionality of A" - that's what describes the relations
between bacula-director-sqlite3 and sqlite best IMO, though, for most
dist-upgrade safety, "recommends" is better.
So, the overal suggestion: is it possible to move sqlite from "Depends:" to
"Recommends:" list of bacula-director-sqlite3?
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable'), (480, 'stable'), (450,
'unstable'), (400, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.35-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages bacula-director-sqlite3 depends on:
ii bacula-common 5.0.2-2 network backup, recovery and verif
ii bacula-common-sqlite3 5.0.2-2 network backup, recovery and verif
ii bacula-director-common 5.0.2-2 network backup, recovery and verif
ii dbconfig-common 1.8.46 common framework for packaging dat
ii debconf [debconf-2.0] 1.5.36 Debian configuration management sy
ii file 5.04-5 Determines file type using "magic"
ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib
ii libgcc1 1:4.4.5-6 GCC support library
ii libpython2.6 2.6.6-6 Shared Python runtime library (ver
ii libsqlite3-0 3.7.3-1 SQLite 3 shared library
ii libssl0.9.8 0.9.8o-2 SSL shared libraries
ii libstdc++6 4.4.5-6 The GNU Standard C++ Library v3
ii libwrap0 7.6.q-19 Wietse Venema's TCP wrappers libra
ii sqlite 2.8.17-6 command line interface for SQLite
ii sqlite3 3.7.3-1 A command line interface for SQLit
bacula-director-sqlite3 recommends no packages.
bacula-director-sqlite3 suggests no packages.
-- debconf information excluded
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
