Ping? El sáb., 4 de ago. de 2018 17:05, Lisandro Damián Nicanor Pérez Meyer < [email protected]> escribió:
> Those intersted in avoiding qtchooser, please take a look at this proposal > for > Qt's devel mailing list. Thanks!! > > --- > > Hi! I would like, this time with enough time, to bring to the table > something > that caused us distros some irks in Qt 5: binaries naming. > > The problem is, I think, easy to explain: some binaries had the very same > name > for Qt 4 and 5: moc, uic, rcc, qdbus to name some of them. > > Before qtchooser came in a user could not have the same tool installed at > the > same time for both versions, or would have to put them in another place > other > than /usr/bin or rename them or... > > Admittedly we distro maintainers came up with the issue too late in the > development process (or at least as far as I know), so Thiago created > qtchooser which kind of solved the major issues, but not without drawbacks. > > From the [list] of bugs it has in Debian in particular, the most > interesting > one is that we can not depend upon the binaries it [masks]... simply > starting > by the fact that two packages can provide that dependency. > > [list] <https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=qtchooser> > [masks] <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712264> > > Let's suppose for a minute that Qt 5 and 6 both provide qdbus (could have > been > any other app) and that there is a Qt 6 app calling it. Currently the app > is > not required to pass -qt6 as a parameter as qtchooser is not mandatory. > Following current practices we have both Qt 5 and 6's qdbus installed. > There > are some possible scenarios: > > - Qt 5 is the default version to use. > > * qdbus has not changed in Qt 6, so Qt 5's version handles the call > correctly. > * qdbus has changed in Qt 6, so Qt 5's version fails. > > - Qt 6 is the default version to use: nothing happens. > > Now make the app a Qt 5 one and invert the scenarios. And let's hope we > get > rid of Qt 4 in the meantime. > > The best solution that we could think of would be to add the major version > to > Qt 6's provided binaries, at very least for the ones that keep their name > from > Qt 5: uic-6, rcc-6, etc. (another scheme might be preferred, like maybe > uic6). > > Note: we are open to other solutions, we have time to discuss this and try > to > get a good solution in time. > > Maybe we can relax this for build-time tools if qmake is dropped and the > next > buildsystem can use the right tool without the need of special switches, > as > currently happens with CMake. > > I also understand that this might not affect other platforms like Windows, > but > a move here ideally would need to be done for all platforms for > consistency. > > I would like to acknowledge that some people might find qtchooser useful, > so > I'm not really proposing to remove it but to have another solution around. > Those who install qtchooser would do it because they know what they are > doing, > maybe even testing different Qt compilations in the same machine. > > Cheers, Lisandro. > > -- > Lisandro Damián Nicanor Pérez Meyer > http://perezmeyer.com.ar/ > http://perezmeyer.blogspot.com/
-- https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-kde-talk
