Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Note: people receiving this mail through the arm/ports/pkg-kde-talk mailing
list:
please reply to the bug.
Hi everyone! First of all please bare with me and try to read the whole mail
before replying. This might look like a hairy thing, but we Qt maintainers think
that there is a chance of making things better and easier for all of us in the
future.
As you may know Qt has a typedef [DISCLAIMER] named qreal which is defined as
double for almost all archs except arm* (and specifically for Debian, sh4),
where is it bound to float.
While in Qt4 this will still be valid, in Qt5 (not yet shipped in any Debian
stable release nor available as a backport) upstream changed qreal to be double
on all platforms by default, adding a compile-time switch to be able to change
it's value if needed. That sounds really good, except for the fact that this
will happen in 5.2.0... without a SONAME bump.
We could easily just use the switch in the appropiate archs and be done. Yes,
this could simply work but we think there is a chance to make things better with
some little effort from us. But first let's try to enumerate what are the
benefits and downsides of doing this.
Suppose for a moment we set qreal to double for all archs. This would mean:
- And ABI change (either with/without SONAME bump, see later)
- Less porting problems like [PORT], thus easier code/transitions.
- Possibly better real handling in all archs, even if that might mean a slow
down for some things. I can push rc1 to experimental with qreal=double for all
archs if you want to test (or some other place if someone can provide the
bandwith).
- No slow down for OpenGL stuff: this part of the Qt5 API has been written
explicitely with float.
- We already have ARM hardware with hard float support and it wouldn't
surprise me this will get more common and faster in the following years, and
this is a decisition which would expland all over Qt5's life span, which we
could expect to be at least 10 years from now judging from Qt3/Qt4 experience.
Now let's analyse Qt5's current situation on Debian:
- It currently has, appart from the ~14 source packages that make the Qt5 stack
and needs a sourcefull upload, 4 reverse dependencies, one being the python
Qt5 bindings and three apps.
- It has never been shipped on a Debian stable release nor in backports.
So we are left with the SONAME bump thing. We Qt maintainers consider that
trying to be somehow binary compatible with other distros is a worthwhile goal.
Of course, this includes not bumping the SONAME.
I've called other distro's maintainers in Qt's devel ML [QTMSG] with little
feedback and over IRC to Fedora and OpenSuse people. Over Fedora lands, one
Qt maintainer told me they where going to push the ABI change without SONAME
bump while an ARM maintainer cried for a SONAME bump. I had no reply from
OpenSuse.
I have also asked to the Ubuntu guys, but I sincerely forgot if they are waiting
to see what we are going to do, switch without soname bump or doing more tests,
and I left my logs at my other PC :-(
So we think the best thing we could do is, for this very exceptional case, set
qreal to double on all archs and break ABI on arm* and sh4, which could be fixed
by [bin]NMUing the three apps that currently build-depend against it (I think
python's bindings will need a sourcefull upload too).
Now I want to be *clear* that if not bumping the SONAME is not a solution then
I'll simply keep armel, armhf and sh4 with qreal=float and be done.
So I would like what the RT and arm* porters thinks.
As a complementary note, Qt 5.2.0's release is expected around christmas.
Thanks a lot for reading, Lisandro.
[DISCLAIMER] I'm clerly not in the position of making this typedef go away,
so please don't insist with this.
[PORT]
http://lists.alioth.debian.org/pipermail/pkg-kde-talk/2013-November/001855.html
[QTMSG]
http://lists.qt-project.org/pipermail/development/2013-November/014017.html
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.10-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20131203180918.7215.8716.report...@dumbledore.dumbledore.com.ar
