[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#897667: qt4-x11: Please add support for new architecture "riscv64"



2018-05-05 1:17 GMT+02:00 Lisandro Damián Nicanor Pérez Meyer
<perezmeyer@gmail.com>:
> El viernes, 4 de mayo de 2018 13:45:08 -03 Manuel A. Fernandez Montecelo
>>
>> 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.
> [snip explanation that rdeps != bootstrapping a new arch]
>> 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.
>
> ACK, and thanks a lot for the detailed explanation :-)

Hey, don't worry, it's also confusing for me.

Not long ago I thought that the new default method using "dose" would
print all the tree of dependencies, but although it prints a bit more
than the simple direct ones that build-depend on the package being
asked, it's not the full tree by any means.

It also surprised me that Qt4 would be so deep-rooted.  I though that
only packages depending directly on the toolkit and not ported would
be involved, and hoped to not have to deal with qt4-x11 at all for
this new port, but things turned to be otherwise :(


>> 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 :(
>
> Exactly.

As I said in the previous email and what another person wrote in
private related to this question, I think that removing it from
libffado, fcitx and phonon goes already a long way.

I also just noticed these that might be in your hand to remove soon-ish:

plasma-theme-oxygen depends upon kde-style-oxygen-qt4 (= 4:5.12.0-2)
kde-style-oxygen depends upon kde-style-oxygen-qt4
soprano-daemon depends upon libqt4-dbus (>= 4:4.5.3)

At least, when I remove libqt4* from my system, it's only libqt4* and
kde4 stuff (kamerka, katepart) , plus a few specific packages like
phonon and these 3 that I mention above.


> Given all the above I'll try to push Qt4 tonight. If in 24hs I do not get to
> do it please do no heasitate in NMUing (or waiting a little more until I or
> someone else in the team gets to it).

Don't worry, it's not that urgent, but I appreciate the effort.

Like for qtbase* in qt5, we can use "unreleased" suite, and the
buildds pick up the dependency for it.

It is a problem in the long term, thinking in months, because at some
point the packages need changes, get entangled in transitions, etc, so
the packages to "unreleased" sometimes have to be refreshed and it's a
hassle.  We have 40~80 there, while we solve problems with their
build-deps or send patches that need to be accepted, so sooner or
later some of them needs to be refreshed.

But I hope that it's not the case of Qt4, specially since it's not
supposed to change much :)


>> > 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/
>
> gdb! That might be comming from the initial packaging and might be a leftover
> from qt4. I have already filed a bug against the source to check that, as I
> think it is not really used. See, something good might come out of all this
> after all :-)

Heh, good news :)

And don't worry really, I expect that people are reluctant to modify
packages that are obsolete long ago.

I co-maintain libsdl1.2 ones, which have the same problem, obsoleted
since 2012 but still more popular than libsdl2 :(

>> 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).
>
> Gracias for that Manuel!

De nada ;-)

I just sent a request to update symbols of kdeclarative, some packages
will need updates on the Debian side at least.

(I don't say this as a request to fast-track that change, I also added
it to "unreleased" so no rush, but I say this as an example that some
packages of Qt5/KDE5 will need modifications, even if some for some
changes we send directly upstream).


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo@gmail.com>


Reply to: