Hello,
Afaict[1] cups would be ready at next time the testing scripts run,
safe for this issue:
#255539 libqt3c102-mt: shlibs needs bump for plugin bic change
Afaik kdelibs is directly suffering from this bug, it needs the new qt
but does not depend on it, therefore I've submitted a dummy-bug
against kdelibs (256690) to inhibit kdelibs to propagate to testing
without updated qt[2].
The qt-maintainer will[3] not make an upload to fix this bug, he wants
to wait for qt-x11-free 3:3.3.2-0pre2 being accepted into experimental
(it is in queue/new) and will upload it to unstable soon afterwards.
Afaict this leaves these possibilities to solve the issue:
#1 tag 255539 sarge-gnore or downgrade it temporarily and close #256690
#2 Kick the qt maintainer or NMU.
#3 Wait. (until qt-x11-free 3:3.3.2-0pre2 is ready for sarge.)
#4 If qt3 really broke back- _and_ forwards-compatibility (and [2]
suggests this) the only *proper* solution might be renaming the binary
package.
I am not very happy with #1 but the alternatives #2 and #3 are only
slightly better, #4 will take months, and the cups-issue should be
resolved fast imho.
Comments, opinions?
On a sidenote, I wonder whether this hint by vorlon
hint cupsys/1.1.20final+cvs20040330-4 kdelibs/4:3.2.3-2
is enough, I'd have thought we'd need a hint for all
grep-available -FDepends -sPackage libcupsys2-gnutls10
together.
cu andreas
[1] My record of parsing release issues is stricingly bad, though.
[2] Having updated qt without updated kdelibs might also be fatal. -
At least the combination new-qt + old-kdelibs temporarily broke any
build of a KDE package on the alpha autobuilder.
[3] At least I've tried to coerce him in vain on IRC.
--
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"
