Thiago Macieira wrote:
> Please list them again, so we can address them. The one I can remember now
> is the default config file for multilib, which is fixable by using
> alternative. Multilib development is covering the sun with a sieve, so
> pardon me if I don't give it too high a priority.
The
Thiago Macieira wrote:
> Now we have a legacy to keep, so we can't accept a radical change. Only
> incremental improvements.
You will find that very few deployments out there in the real world use
qtchooser. The widely-used RHEL most definitely does not, it inherits the
exact same Qt setup Fedor
On Sunday 18 January 2015 06:08:47 Kevin Kofler wrote:
> Thiago Macieira wrote:
> > Unanimity was not required. Only consensus and that was achieved. The
> > requests for renaming were argued and heard (I argued for them myself, I
> > even prepared patches and had the solution in progress) but in t
On Sunday 18 January 2015 06:15:45 Kevin Kofler wrote:
> I wrote:
> > I also see how it happened: You were convinced that it was possible to
> > solve the problem in a different way (qtchooser) and so accepted to
> > implement that. Unfortunately, that implementation does not fulfill the
> > distri
On Sunday 18 January 2015 05:56:29 Kevin Kofler wrote:
> If qmake IS the build system, it's as for the -qt5 suffix,
> the user will have to run the proper mingw32-qmake-qt5 there, no surprises
> in this case. (This is already the recommended way to handle this in
> Fedora.) As for any other buil
I wrote:
> I also see how it happened: You were convinced that it was possible to
> solve the problem in a different way (qtchooser) and so accepted to
> implement that. Unfortunately, that implementation does not fulfill the
> distributions' actual requirements, so we are back to square one.
PS:
Thiago Macieira wrote:
> Unanimity was not required. Only consensus and that was achieved. The
> requests for renaming were argued and heard (I argued for them myself, I
> even prepared patches and had the solution in progress) but in the end the
> consensus was another way. Now everyone, including
Thiago Macieira wrote:
> Right. That would reduce from 4 to 2 targets you need to support. Since
> it's more than 1, the use-case remains.
For the MinGW stuff, I consider it the build system tool's job to support
the cross-prefix for all binaries. The autotools automatically add that
prefix to a
On Sunday 18 January 2015 04:37:50 Kevin Kofler wrote:
> > Moreover, the config files are text, they don't belong in /usr/lib.
>
> .pc files are text too. They belong into /usr/lib* because they depend on
> the architecture and thus need to be multilibbed, and /usr/lib* is the only
> multilibbed s
On Sunday 18 January 2015 04:07:02 Kevin Kofler wrote:
> > - it was agreed upon in 2011
>
> Fedora never agreed to the solution that was implemented. It clearly does
> not fulfill our requirements. Never did, never will.
Unanimity was not required. Only consensus and that was achieved. The reques
Thiago Macieira wrote:
> It would have been nice to know this limitation when we were designing the
> solution. Other distros don't seem to have this problem because the 32-bit
> package on a 64-bit system does not seem to have clobbered files.
Even we did not know it. We only found out when we st
Thiago Macieira wrote:
> Reasons:
> - "etc" = 37 different binaries
That's what scripts are for. (How do you think we do the renames in the
Fedora packages?)
> - inserting the argv check for the warning, as you suggest, in each of
> them is work we'd rather not have and also which can go subtl
On Sunday 18 January 2015 02:29:14 Kevin Kofler wrote:
> > Because it also works for those of us who have multiple Qt 5 builds. I can
> > run:
> > qmake -qt5
> > qmake -qt5-release
> > qmake -qt5-icc
> > qmake -qt5-clang
> > qmake -qt5-mips
> > qmake -qt5-static
> > qmake -qt5.1
>
> Well, you coul
On Sunday 18 January 2015 02:41:52 Kevin Kofler wrote:
> Oh, and another inherent complication that Rex Dieter (our qtchooser
> packager) reminded me of: In Fedora, we support multilib. Now
> /etc/xdg/qtchooser is a non-multilibbed path. If we install an
> /etc/xdg/qtchooser/5.conf in both qt5-qtba
2015-01-18 4:46 GMT+04:00 Kevin Kofler :
> Konstantin Ritt wrote:
> > As a developer, I would rarely use the only Qt version provided by the
> > distro. In fact, I currently have 8 different Qt-5 builds (partially
> > because of some projects are sticking to some particular Qt-5
> > version/config
Thiago Macieira wrote:
> Which implies that the Qt 5 development files install a "5.conf" global
> configuration file. That's all.
Oh, and another inherent complication that Rex Dieter (our qtchooser
packager) reminded me of: In Fedora, we support multilib. Now
/etc/xdg/qtchooser is a non-multil
Thiago Macieira wrote:
> You're talking about a buildsystem that runs qmake? I was thinking of the
> buildsystem being qmake itself, in which case the task of running qmake
> falls on the packaging system (your .spec file).
Yes, I'm talking about a non-qmake build system that builds Qt stuff, that
Konstantin Ritt wrote:
> As a developer, I would rarely use the only Qt version provided by the
> distro. In fact, I currently have 8 different Qt-5 builds (partially
> because of some projects are sticking to some particular Qt-5
> version/configuration/etc.)
In practice, using the latest works i
On Sunday 18 January 2015 01:05:50 Kevin Kofler wrote:
> Thiago Macieira wrote:
> > The one requirement that came from the Qt Project was that the tools would
> > not be renamed.
>
> And the one requirement that came from the distros was that the tools must
> be renamed. This was made very clear
Thiago Macieira wrote:
> To be clear: the reason people didn't want the renamed qmake was exactly
> because people had build scripts and didn't want to update them, as Qt 5
> is mostly source compatible with Qt 4.
In practice, applications typically support only one or the other, only some
librar
As a developer, I would rarely use the only Qt version provided by the
distro. In fact, I currently have 8 different Qt-5 builds (partially
because of some projects are sticking to some particular Qt-5
version/configuration/etc.)
Having just a "qmake-qt5" solution doesn't fit my purposes; adding so
Thiago Macieira wrote:
> So, yes, qtchooser is the next best thing. But you're refusing to adhere
> to the common way. Fair enough, I'll just recommend anyone using Fedora
> packages in #qt to go to #fedora, since you're refusing to standardise...
qtchooser is available in fedora, but is opt-in.
Oh and…
Thiago Macieira wrote:
> Which implies that the Qt 5 development files install a "5.conf" global
> configuration file. That's all.
… since this was never communicated that to us (at least not in any place
that we have read), the current Fedora packaging of qtchooser actually uses
qt5.co
Thiago Macieira wrote:
> The one requirement that came from the Qt Project was that the tools would
> not be renamed.
And the one requirement that came from the distros was that the tools must
be renamed. This was made very clear from the beginning. All other solutions
are and will always be inh
On Saturday 17 January 2015 15:32:42 Thiago Macieira wrote:
> Will not happen for Qt 5. Simply can't. If you have a time travel machine,
> go back to 2011 and convince people that this was acceptable. Renaming the
> binaries was the one thing that the majority of Qt developers did not want.
To be
On Saturday 17 January 2015 23:46:58 Kevin Kofler wrote:
> Thiago Macieira wrote:
> > packagers, like we did in the past for qtchooser (a solution designed for
> > distro's needs).
>
> Hahaha, that's a good one!
>
> Qtchooser is designed completely PAST distros' needs and entirely useless
> for d
Thiago Macieira wrote:
> packagers, like we did in the past for qtchooser (a solution designed for
> distro's needs).
Hahaha, that's a good one!
Qtchooser is designed completely PAST distros' needs and entirely useless
for distros. What we actually asked for (and have always been shipping, and
27 matches
Mail list logo
