On Mon, Jul 28, 2025 at 08:38:41AM +0200, Fab Stz wrote:
Thank you Paul for having attended the talk on Qt for Android at DebConf25.
Thanks for giving it, Fab!
Once you have discussed the chanlenges of this package with the team, would you please share the outcome on the ITP [1] (which I actually changed back to RFP)? That way any future maintainer would be up to date with regard to how the pending chanlenges could be overcome.
I'll reply now -- I've got my notebook open and here are some notes I had from the session; happy to talk it over further with the team but here's a 'first pass' anyway.
I think there's nothing inherently wrong with the package's aim. There's nothing, on principle, that would stop this from being included in the
non-free section of the archive.I did pick up on a few things that I think need to be addressed before uploading it to the archive:
One of the first things that jumped out was the way in which this package builds. IIRC, the android ndk (due to being out of date in Debian[1]) was downloaded at build-time. All builds (even nonfree!) should be building without network. For main and contrib this would be a hard reject. I think we'd apply the same standard for non-free. If the NDK can't be updated (or this be changed) due to distributibility issues, that's also something that would need fixing :)
The next was social in nature -- this feels like something that should be done with, at minimum, the consent of the Qt team. Having two different Qt packages in the archive is one thing (I'm sure someone will have heartburn over that), but having them configured differently has a potential for causing some real hard confusion for everyone involved :). I understand (and am sympathetic!) that the Qt team doesn't want to maintain this -- I think that just means whoever does maintain this package ought to jump in to get involved with the Qt team in Debian, and ensure that Qt team norms apply to this package too, even if the android Qt varient isn't a team package. I'm sure the Security team would have some thoughts which may be helpful to solicit and consider, but I also don't think they care too much about non-free; they have their hands full with main.
Lastly, I think the final big flag was "It needs a maintainer" :) -- I heard you mention you were finishing this enough to "scratch your itch" with welle, but to include this in the archive, we'd need a willing and active maintainer to take on this truely massive maintance burden.
After all, the Qt package, as prepared, has more build components (including full forked Chromium!) than the version in main, and this package, plus an ecosystem of dependent packages would fall onto this one person. We'd likely need to carry most if not all of the Debian Qt patches against Qt in this package too, after all.
It may be worth trying to do this after there's a team of folks who have experience with the Debian Qt team -- so they understand conventions, norms, and tools related to Qt packaging, even if, again, this isn't part of the Qt team.
Thanks for your work, it was an interesting talk! paultag [1]: Someone should really file a RoM or RoQA on that package -- ⢀⣴⠾⠻⢶⣦⠀ Paul Tagliamonte <paultag> ⣾⠁⢠⠒⠀⣿⡁ https://people.debian.org/~paultag | https://pault.ag/ ⢿⡄⠘⠷⠚⠋ Debian, the universal operating system. ⠈⠳⣄⠀⠀ 4096R / FEF2 EB20 16E6 A856 B98C E820 2DCD 6B5D E858 ADF3
Attachment:
signature.asc
Description: PGP signature