Ensuring complete upgrades in applications with multiple binary packages
- To: debian-devel <firstname.lastname@example.org>
- Cc: email@example.com
- Subject: Ensuring complete upgrades in applications with multiple binary packages
- From: Frank Küster <firstname.lastname@example.org>
- Date: Tue, 15 May 2007 16:28:39 +0200
- Message-id: <[🔎] email@example.com>
- In-reply-to: <20070515121034.GE13847@gamma.logic.tuwien.ac.at> (Norbert Preining's message of "Tue\, 15 May 2007 14\:10\:34 +0200")
- References: <firstname.lastname@example.org> <20070510130826.GB2108@PC23> <email@example.com> <firstname.lastname@example.org> <20070515121034.GE13847@gamma.logic.tuwien.ac.at>
we've run across a problem with our texlive packages, and I'd like to
get some opinions, in particular regarding dpkg behavior.
TeX Live is one big thing upstream (one DVD) and has been split for
Debian packaging into one arch:any and four arch:all source packages
with numerous binary packages each. Generally, you cannot assume a
system to work properly which has a mixture of different upstream
versions of these packages installed. But how should we achieve that?
A. The straightforward approach is the most ugly one: The packages of
course frequently declare "Depends: texlive-some-other-package", and
we could switch all of these depends into versioned depends, (>=
$upstream-version). But that would really look ugly, e.g. from
-Depends: preview-latex-style, texlive-common (>= 2007), texlive-pictures, texlive-latex-base
+Depends: preview-latex-style, texlive-common (>= 2007), texlive-pictures (>= 2007), texlive-latex-base (>= 2007)
It would require a really big change to our internal packaging
scripts to add such version restrictions only where a real
incompatibility shows up, so it would have to be each of them.
B. texlive-common could declare
But how would that work upon upgrade? Technically, there's no
problem, first all texlive packages except texlive-common would be
unpacked, then texlive-common could be unpacked and configured, after
that the others can be configured.
But usually dpkg tries to do unpacking and configuring in the same
order; would it be confused by this situation?
C. Ignore the problem and just expect from users to handle their
upgrades in a sane way and not put individual packages on hold? Of
course, other reasons like unrelated errors during dist-upgrade might
also cause version mixes, but again the sane thing to do would be to
run dist-upgrade again, and not try to use the packages or report a
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)