Hi dear Release Team,
Following the previous discussion in http://lists.debian.org/debian-
release/2010/08/msg00062.html
I uploaded new upstream versions of the following packages (all Build-Depending
in chain without any reverse depends) to experimental:
* apiextractor 0.7.0-1~exp2
* generatorrunner 0.6.0-1~exp0 (B-D on a )
* shiboken 0.4.0-1~exp1(B-D on a,g )
* pyside 0.4.0-2 (B-D on a,g,s )
Actual sid/squeeze versions are outdated and ships some RC bugs:
- #590302 on apiextractor that impacts shiboken which then prohibits armel and
sparc build for the whole chain;
- #588556 (= #588558) on pyside, which is a segfault in the QtGui module (aka
nearly unuseable)
Hence, the versions actually in experimental fix those 3 RC bugs and "enable"
two more architectures: armel and sparc (the first being particularily
important
for PySide).
The fix for #590302 is backportable, but the fix for #588556 is hardly, as the
codebase changed "quite a lot".
== What would this bring to Squeeze? ==
Nokia (new Qt owners) released a PyQt [GPL] replacement: PySide [LGPL]
(together
with a set of tools to build it: apiextractor, generatorrunner, shiboken). No
other package depends on pyside (python-pyside.* binary packages) right now,
but
since PySide has compatible API with PyQt and it's used in Maemo, I think it is
worth to get it into Squeeze.
Furthermore, as the OpenBossa guys (PySide's upstream) are now "approaching"
the
"1.0" release, the API is slowly stabilizing at the cost of "often" bumping the
SOVERSION (in many cases "just to be sure", but not necessarily for good
reasons).
So in short, I think that having the "most recent possible" version of PySide
and its B-D chain is good for Squeeze, with the extra bonus that nothing
depends
on PySide (yet). And having the most recent PySide in Squeeze will allow users
to build new things on PySide (which would not be the case with a segfault'ing
QtGui).
[ Note that I am very aware of the freeze and what that means, still I think
that PySide as almost-zero-risk (no B-D) is worth discussing. ]
So from here I see some options (with my opinion in parentheses)
i) Removing PySide from Squeeze
(I think it would be sad).
ii) Keeping the current PySide in Squeeze and request the maintainer (me) to
provide patched versions
(This option needs hard work for me, with unknown success chances. The
fallback being the removal (i) doesn't help.)
iii) Allow the PySide version currently in experimental to unstable->squeeze
(This is IMHO the easiest way to fix the RCs while still being zero-risk and
also implies an "almost-1.0" PySide for Squeeze, which would be
satisfactory for both upstream and myself.)
iv) Allow me to upload the latest upstream releases to experimental and report
the discussion to later times, with more recent upstream releases
(This is obviously the preferred solution for upstream who doesn't want
"outdated" versions in distributions. I very much understand why allowing
this could not be possible. Furthermore, two updates that upstream wanted
in are already in as patches [0,1], with one "cheated in" (it breaks the
API, but I kept the SOVERSION)
So personally I would rank the options from latter to first: iv) is preferable,
i) is the least preferable.
So the decision is now in your hands and I thank you in advance for taking it!
Cheers, OdyX
[0] http://patch-
tracker.debian.org/patch/series/view/apiextractor/0.7.0-1~exp2/u_d13ce132_non_final_method_is_not_necessarily_polymorphic.patch
[1] http://patch-
tracker.debian.org/patch/series/view/shiboken/0.4.0-1~exp1/u_1eda671_fix_type_resolver_algorithm.patch
--
Didier Raboud, proud Debian Maintainer (DM).
CH-1020 Renens
did...@raboud.com
signature.asc
Description: This is a digitally signed message part.
