Bug#897667: qt4-x11: Please add support for new architecture "riscv64"
Hola!
2018-05-04 12:47 GMT+02:00 Lisandro Damián Nicanor Pérez Meyer
<perezmeyer@gmail.com>:
> ¡Hola Manuel!
>
>> We need support in this package to bootstrap the riscv64 architecture.
>>
>> Yes, I know that you want to get rid of Qt4 once and for all and ASAP, and I
>> fully agree with the goal. However, a bazillion of packages depend on
>> qt4-x11 indirectly,
>
> A little less than 300 source packages.
300 is a very low estimation/calculation, if you're using something
like "build-rdeps" it doesn't tell the whole picture at all, at least
for new ports.
Let me dig through the dependency graphs in some detail.
"build-rdeps --old qt4-x11" says:
Found a total of 226 reverse build-depend(s) for libqt4-dev.
This includes things like phonon, automoc, kde4libs, fcitx, and
python-qt4, which then expands the dependency tree to:
Found a total of 20 reverse build-depend(s) for python-qt4.
Found a total of 46 reverse build-depend(s) for libphonon4qt5-dev.
-> this includes okular, plasma-desktop... most of KDE-5
Found a total of 29 reverse build-depend(s) for fcitx-libs-dev.
-> this includes libsdl2, with 100 rdeps as we'll see later
This alone is 300 or more (it depends if the sets of packages overlap,
but rdeps of qt4 and libsdl2 don't overlap much).
automoc is an interesting one to look at, initially only has a few:
kde4libs
polkit-qt-1
akonadi4
Found a total of 3 reverse build-depend(s) for automoc.
But it turns out that kauth (kde5) depends on polkit-qt1:
lxqt-policykit
calamares
libqapt
polkit-kde-agent-1
kauth
Found a total of 5 reverse build-depend(s) for libpolkit-qt5-1-dev.
And lots of KDE things depend on kauth:
Found a total of 18 reverse build-depend(s) for libkf5auth-dev.
- includes plasma-desktop, baloo-kf5, kconfigwidgets
So basically, since half of KDE5 depends on kauth, which depends on
polkit-kde-agent1, which depends on polkit-qt1, which depends on
automoc, which depends on qt4-x11, KDE5 cannot be built until qt4-x11
is built and crossing fingers that all other deps are available.
(Or otherwise the chain of deps would need to be broken somewhere, but
that needs one of these:
a.- "forking" the packages in Debian until qt4-x11 is removed
completely, which will not happen in months even in the most
optimistic scenarios
b.- get patches in dozens of packages to not depend on qt4
specifically in riscv64, instead of just getting qt4-x11 to work
).
So as we can see, just because automoc depends on qt4-x11, all of KDE
depends on it, even if KDE itself moved to Qt5.
Let's look at another case not related with the one above, but also
with deep entangle of dependencies involving Qt4.
One of the deps that need python-qt4 and python-qt4-dbus is libffado,
on which only two packages depend:
jack-audio-connection-kit
jackd2
Found a total of 2 reverse build-depend(s) for libffado-dev.
For the first of them (not looking at the second):
Found a total of 152 reverse build-depend(s) for libjack-dev.
-> includes pulseaudio and vlc
pulseaudio is a dependency of libsdl2, and half of Debian really:
Found a total of 100 reverse build-depend(s) for libsdl2-dev.
- includes ffmpeg
Found a total of 151 reverse build-depend(s) for libpulse-dev.
- includes, among many others:
cinnamon,
empathy,
gnome-shell, gnome-control-center,
mate-settings-daemon,
efl (enlightenment),
kde-runtime,
pyqt5,
phonon,
vlc, ffmpeg, mpv, mplayer,
wine
Deps of ffmpeg:
Found a total of 110 reverse build-depend(s) for libavcodec-dev.
-> this includes things like vlc
So in this second case, because libffado depends on python-qt4*,
pulseaudio and therefore almost all media and desktop packages are
affected by this, and cannot be built.
So in short, really, about half of Debian depends on qt4-x11 in one
way or another, including ironically KDE, that moved away from Qt4
long ago.
>> for example libsdl2 needs it (through fcitx, then
>> cmake-extra-modules, then qt5-qmake, then qtchooser that depends on Qt4
>> stuff); many package still need it directly; etc.
>
> fcitx: yes. The rest: they do not need Qt4. But the sole fact that you mention
> it means we better take a look here. Please give us more info with respect how
> this is happening (or something I can dig into).
So as I explained, there are many examples above of dependency cycles
that involve Qt4.
Perhaps fcitx is not the best example if you consider isolatedly, but
libsdl2 that needs to have fcitx installed to be built, or phonon and
others with pulseaudio, depend indirectly on Qt4 via several packages,
and all important media stuff and desktops depends on that.
> Let's try to see exactly what's happening here, the list you wrote here look
> really suspicious to me.
I hope that you find all sorts of interesting cycles to follow in what
I wrote above. I fear that the ones that I analysed more closely
above are only the tip of the iceberg, but many more packages will
need disabling Qt4.
>> I am attaching a patch that adds support for the architecture. AFAIK
>> (please confirm) upstream doesn't accept patches since long ago, so no
>> point in sending it there.
>
> Yes, Qt4 is **dead** upstream. Adding whatever support means becoming it's
> maintainer. And adding more probable life to something that should be not be
> here already.
As I said, we already have this in unreleased, is impossible to get to
>60% of the archive built without qt4 (or else hacking in dozens of
packages to remove support from Qt4, and keep a fork of all of them
for this port, which is a worse option).
So it would be nice to have this patch it in the main package so we
don't have to rebuild it from time to time if we need the changes.
But there's no other option for us than to have it, really.
>> For Qt5 we're already sending it upstream, e.g.
>> webkit stuff.
>
> *Thanks* a lot for that. If you need help prodding upstream please be sure to
> contact us.
>
>> It would be great if you could include these changes and release a new
>> version for unstable, for the time being the patched version lives in
>> "unreleased".
>
> I must admit that the patch looks good. But before accepting it I really want
> to dig into the dependency chain you wrote above. This seems like a great
> opportunity to find possibly wrong stuff.
Yeah, I agree.
For example, the major ones that I see at the moment are:
- libffado should stop depending on python-qt4*, so pulseaudio or
libsdl2 doesn't depend indirectly on Qt4 (through
jack-audio-connection-kit and jackd2).
- phonon direclty depends on libqt4-dev too, so it needs to go.
- fcitx needs to stop depending on it, so libsdl2 and its deps like
ffmpeg don't (indirectly) depend on Qt4.
I think that with those three, a lot of ground is already covered.
The good part is that second-level dependencies like "jack*" and
libsdl2 don't need to be modified in principle, they don't use the qt4
stuff of libffado or fcitx directly; so a rebuild of fcitx and
libffado without Qt4 support shouldn't affect (most of) the packages
that depend on it.
This is a chicken and egg problem though, because maintainers don't
want to remove support until Qt4 is really going away, and this kind
of migrations of "everything going together at once" is always
painful. Two ones come to mind: IPv4/6 and Python2/3 :(
> By the way: in http://deb.li/qt5builds I noticed that most qt5 submodules have
> been built but not qtbase! How did you achieve that?
Basically, we achieved it by disabling firebird3.0 and gdb as build
deps, and related packages, which are not yet ready, debdiff:
http://paste.debian.net/hidden/3fcebf14/
I submitted a bug for firebird3.0, but still couldn't get it to build
cleanly; and gdb still needs the port of RISC-V merged and then that
version uploading to Debian.
Similar to qt4-x11, a version of qtbase is living in "unreleased".
In that case we prefer to not submit these changes to you because we
hope to get them sorted out in a reasonable timeframe, so it would
mean extra work for you with little gain (to first add exceptions for
this arch, then remove them).
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montezelo@gmail.com>
Reply to: