Oswald Buddenhagen wrote:
> but that work has already been done, long ago. even adjusting it to qt6
> at some point will be a rather trivial effort (and zero for you if you
> bothered to upstream build system improvements that make upstream
> packages work out of the box with packaged qt).
We do that. The problem is that some upstreams are not cooperative and blame
us for "breaking" Qt instead, most notably the Qt Project itself (see also
Thiago's replies), which is upstream for more than just core Qt.
> but this is already the case, and has been since qt2. so that ship has
> sailed. in fact, when rex was pushing for the qmake-qt5 scheme, the
> debian (?) guys made clear that they'll keep their qmake5 (?) scheme
> anyway - they must, for compat reasons. so whatever we do is add-on only
> anyway.
I'm not aware of any distribution actually using the "qmake5" naming scheme
for the binary, and a quick Internet search doesn't find anything. Mandriva
names its package that way, but the binary contained in it is actually
called "qmake-qt5". (So that's another distribution using our naming
scheme.) Debian is now using qtchooser. (But have they ever shipped a
"qmake5" to begin with?)
And if there is one, they can easily ship a qmake5 → qmake-qt5 symlink.
Having the qmake-qt5 name standardized upstream would force them to support
it in addition to the legacy one.
> and if a *new* distro chooses *yet* another scheme ... well, shoot them.
> i suggested that the qt project should publish packaging guidelines, so
> there would be no need to become homocidal.
The potential for divergence is much less if the package already comes with
usable binary names out of the box from upstream.
> also consider that this problem is "a tad" bigger than just qt. you
> really need to define a cross-distro standard anyway.
The cross-distro standard is normally what upstream ships. The problems only
come up when we have to rename it downstream.
> but as others pointed out, the name clash of qmake from qt4 and qt5 is
> advantageous in some porting scenarios.
The first step of porting needs to be to change the version of Qt used. This
is very commonly the case when porting to a new major version of a library.
The advantage of doing it that way is that we do not rely on the user
compiling the software to pick the correct version of the library, the
software knows what it expects and should pick the right version
automatically.
> and in case of unified dispatchers like qtchooser (and lots of custom
> scripts), divergence would be actively counter-productive.
How so? You could wrap both the -qt5 and -qt4 names, with wrappers using
different config files and/or different environment variables, and so select
both a default Qt 5 and a default Qt 4, or just choose on the command line
(e.g. qmake-qt5 -qt=debug). Trying to build Qt 5 code with your favorite Qt
4 will not work, the selection ought to be separate.
> given that the problems specific to distros have been adequately solved
> (even if you find that hacky - which it certainly is in case of badly
> written build systems), i don't see why we should bother changing
> anything at this point.
In that case, nothing is going to change on our end either, I can live with
that (though I don't like the situation, for the reasons explained above),
but Thiago will not be happy.
Kevin Kofler
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
