Hi guys,
For woody, there've been a few package reorganisations, probably most
notably the whole XFree86 v4 update.
A lot of these updates seem to be breaking forwards compatibility in the
sense that they require lots of packages to be rebuilt on some or all
architectures. For example the X update means dependencies on xlib6g and
xpm4g have to be changed to dependencies on xlibs: for xlib6g there's a
dummy package to handle this, for xpm4g recompiles have to be done [0].
Similarly, the tetex rearrangement wrt tetex-lib and tetex-dev causes
some problems, even though libkpathsea3 provides tetex-dev. In particular,
packages like libkpathsea-perl which specify a versioned dependency on
tetex-lib become broken and need to be rebuilt.
What this generally ends up meaning is that the testing update scripts get
into a bit of a catch-22 situation. Take, for example, the situation with
cjk-latex: the version in unstable depends on libkpathsea3 so it can't be
installed into testing until tetex is; but the version in testing depends
on tetex-lib (>= 1.0.6-2), so it'll become broken if the new tetex is
installed (since provides don't satisfy version dependencies) [1].
So, what's the point of this?
Well, first: please try to avoid it wherever possible. Making a dependency
unsatisfiable is a Bad Thing, and not something to be done if you don't have
a *very* good reason for it.
Second: if you _must_ do it, add a Provides: clause to your new
packages. If there are any versioned dependencies on packages you're
getting rid of, _seriously_ consider making a dummy package like the
xlib6g package from X 4.
Third: when you do it, please make sure the autobuilders and packages
know about it, so that (a) they don't keep building packages with the
old dependencies, and (b) they can reupload any existing packages with
correct dependencies.
Fourth: if, after you've made sure that _all_ packages in unstable,
in _all_ architectures have been rebuilt with the new dependencies,
you find that your package isn't going into testing, mail me so I can
special case the update in the scripts.
For reference, presumably mainly due to issues like this, the uninstallable
packages count on various architectures looks like:
potato woody sid
i386 8 46 138
alpha 68 77 166
sparc 56 75 218
powerpc 77 82 333
m68k 91 125 334
arm 142 268 1858
Note that all these numbers should be 0.
Cheers,
aj
[0] On each architecture, the packages that depend on xpm4g seem to be:
alpha:
xcopilot wmx10
arm:
freeciv-xaw3d pilrc wmx10 xmbdfed xwave
gsumi pixmap xacc xonix
knews ppxp-x11 xbill xpat2
mctools-lite propsel xboing xsoldier
nighthawk wmmand xitalk xtron
i386:
netscape4 xcopilot
m68k:
vice freeamp isdnbutton propsel libforms0.89
xmysqladmin gsumi knews wmx10
powerpc:
vice twcw xtron
coolicon wmx10 communicator-smotif-46
fsviewer wsoundprefs libforms0.88
pixmap xacc libforms0.89
ppxp-x11 xmgr xmame-x
sparc:
gsumi pixmap xacc libforms0.88 xtrojka
knews wmx10 xmgr libforms0.89
There may be more broken dependencies due to the X update too.
[1] The testing scripts can, in theory, handle this automatically. In
practice, it takes way too long to do, especially when there are lots
of large or simultaneous reorganisations happening, or when some of
the reorganisations aren't complete.
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``_Any_ increase in interface difficulty, in exchange for a benefit you
do not understand, cannot perceive, or don't care about, is too much.''
-- John S. Novak, III (The Humblest Man on the Net)
Attachment:
pgpmiGHi9TA_t.pgp
Description: PGP signature