On 20 January 2015 at 05:23, Thiago Macieira thiago.macie...@intel.com wrote:
On Tuesday 20 January 2015 00:47:50 Lisandro Damián Nicanor Pérez Meyer wrote:
I think there is a point which we might be missing in this long thread. For
Qt5 we are not asking for a simple rename because that *would*
Oswald Buddenhagen wrote:
but i do. my purpose was to keep the imo (slightly) detrimental change
out of qt, and enabling our developer use case to be convenient. i never
considered the distro case relevant as such - i demonstrated why it is a
non-issue back then, and i did it again in my
On Mon, Jan 19, 2015 at 07:30:46PM -0800, Thiago Macieira wrote:
On Tuesday 20 January 2015 04:05:20 Kevin Kofler wrote:
Oswald Buddenhagen wrote:
correct. as far as i'm concerned, the purpose of qtchooser is to
be a frontend tool which targets developers working with multiple
qt
Thiago Macieira wrote:
The FHS does not restrict /opt to admin-installed packages. It simply says
add-on application software packages, unlike /usr/local, for which it
says for use by the system administrator when installing software
locally.
Fedora has historically interpreted add-on
On Tue, Jan 20, 2015 at 01:55:41PM +0100, Kevin Kofler wrote:
Some programs need adaptations to build on distros because they do not
expect the binary names we ship.
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
Thiago Macieira wrote:
If we get any issues reported to us about Fedora or RHEL's non-renamed
binaries, we'll send back to you, with the recommendation that people file
bug reports about not using qtchooser. I already do that.
Now you're being a little over-dramatic, imo.
Users in this case
On Tuesday 20 January 2015 13:43:53 Kevin Kofler wrote:
In the Qt case, whether we install the Qt binaries to /usr/lib(64)/qt5/bin
or /opt/fedora/qt5/bin does not really change anything, except that only
the former supports multilib qmake. There can still be only one unsuffixed
binary found
On Tuesday 20 January 2015 11:28:10 Oswald Buddenhagen wrote:
So no, don't tell us qtchooser is not meant to solve distros'
problems. It's meant exactly for them.
but i do. my purpose was to keep the imo (slightly) detrimental change
out of qt, and enabling our developer use case to
On Tuesday 20 January 2015 10:04:51 Thiago Macieira wrote:
On Tuesday 20 January 2015 18:59:46 Kevin Kofler wrote:
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
On Tue, Jan 20, 2015 at 06:59:46PM +0100, Kevin Kofler wrote:
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
Sigh get a room (on irc fex) guys. Mailbox full already ;-).
Andreas Aardal Hanssen
Den 20. jan. 2015 kl. 17.08 skrev Thiago Macieira thiago.macie...@intel.com:
On Tuesday 20 January 2015 11:28:10 Oswald Buddenhagen wrote:
So no, don't tell us qtchooser is not meant to solve distros'
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
On Tuesday 20 January 2015 18:59:46 Kevin Kofler wrote:
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.
On Tuesday 20 January 2015 15:39:28 Oswald Buddenhagen wrote:
[snip]
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
On Tuesday 20 January 2015 19:35:33 Oswald Buddenhagen wrote:
On Tue, Jan 20, 2015 at 10:04:51AM -0800, Thiago Macieira wrote:
On Tuesday 20 January 2015 18:59:46 Kevin Kofler wrote:
given that the problems specific to distros have been adequately
solved (even if you find that hacky -
On Tuesday 20 January 2015 16:01:59 Lisandro Damián Nicanor Pérez Meyer wrote:
On Tuesday 20 January 2015 15:39:28 Oswald Buddenhagen wrote:
[snip]
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
On Monday 19 January 2015 15:01:20 Harri Porten wrote:
On Sun, 18 Jan 2015, 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
On Tuesday 20 January 2015 01:11:55 Lisandro Damián Nicanor Pérez Meyer wrote:
On Monday 19 January 2015 19:30:46 Thiago Macieira wrote:
[snip]
So, as Sune Vuorela also explained, having multiple major versions of Qt
in
parallel is always going to be a fact of life.
Indeed, but
On Tuesday 20 January 2015 01:49:01 Lisandro Damián Nicanor Pérez Meyer wrote:
For the sake of completeness, we are not allowed to do so in the same
strength that the Qt project doesn't allows binary incompatibility
between
minor versions, and for which us downstreamers are very
On Tuesday 20 January 2015 00:57:55 Lisandro Damián Nicanor Pérez Meyer wrote:
qdbus should be the same in all versions. I don't plan on making breaking
changes in the future -- I can't see what I could do to create such
problems...
I just wrote an example in another mail, supposing a
On Tuesday 20 January 2015 00:47:50 Lisandro Damián Nicanor Pérez Meyer wrote:
I think there is a point which we might be missing in this long thread. For
Qt5 we are not asking for a simple rename because that *would* break stuff
for other people, and that's not fair. What we ask is *adding*
On Monday 19 January 2015 18:44:14 Thiago Macieira wrote:
On Sunday 18 January 2015 18:06:45 Lisandro Damián Nicanor Pérez Meyer
wrote:
If I'm wrong then simply unmasking qdbus with qtchooser should be enough.
/usr/bin/qdbus should be provided by the default version (qt4's one in our
case)
On Tuesday 20 January 2015 05:06:10 Kevin Kofler wrote:
Thiago Macieira wrote:
I'm not sure I see the distinction between users and customers here.
When you say users, are you thinking of a person who builds a Qt-using
software from a 3rdparty?
There are also developers who are not
On Tuesday 20 January 2015 05:04:05 Kevin Kofler wrote:
Remember: you (implicitly) agreed with the solution in 2012.
I did not agree with anything at all.
You brought up a discussion on a Qt Project mailing list, to which most
distribution packagers are not even subscribed. You got only
On Tuesday 20 January 2015 05:04:05 Kevin Kofler wrote:
Software on GNU/Linux often gets developed against distribution -devel
packages. I definitely do that whenever possible. Do you really think that
all developers of Qt-using software download your upstream binaries or
build your source
Oswald Buddenhagen wrote:
correct. as far as i'm concerned, the purpose of qtchooser is to be a
frontend tool which targets developers working with multiple qt
versions, regardless whether these versions come from distro packages or
own builds.
The thing is, we asked for something that
On Monday 19 January 2015 20:14:33 Thiago Macieira wrote:
On Tuesday 20 January 2015 00:57:55 Lisandro Damián Nicanor Pérez Meyer
wrote:
qdbus should be the same in all versions. I don't plan on making
breaking
changes in the future -- I can't see what I could do to create such
On Tuesday 20 January 2015 01:01:57 Lisandro Damián Nicanor Pérez Meyer wrote:
On Monday 19 January 2015 18:46:18 Thiago Macieira wrote:
[snip]
As for Designer, the discussion in 2012 was that its output is compatible
with Qt 4 and will remain so, but distributions need to upgrade the
On Monday 19 January 2015 19:07:29 Thiago Macieira wrote:
On Monday 19 January 2015 15:18:41 Lisandro Damián Nicanor Pérez Meyer
wrote:
Distributors are going a great job creating Qt packages. But not
everyone
is using their distro's Qt. In fact, looking at our customers I'd say
that
On Monday 19 January 2015 20:25:55 Thiago Macieira wrote:
On Tuesday 20 January 2015 01:11:55 Lisandro Damián Nicanor Pérez Meyer
wrote:
On Monday 19 January 2015 19:30:46 Thiago Macieira wrote:
[snip]
So, as Sune Vuorela also explained, having multiple major versions of
Qt
in
On Tuesday 20 January 2015 04:05:20 Kevin Kofler wrote:
Oswald Buddenhagen wrote:
correct. as far as i'm concerned, the purpose of qtchooser is to be a
frontend tool which targets developers working with multiple qt
versions, regardless whether these versions come from distro packages or
On Sunday 18 January 2015 22:24:15 Kevin Kofler wrote:
Konstantin Ritt wrote:
There is no need for moc/rcc/uic to be suffixed. In fact, they are an
internal build tools invoked by qmake and thus they should normally reside
in libexec dir (or you may query qmake for its specific libexec dir
On Sunday 18 January 2015 22:24:40 Kevin Kofler wrote:
Thiago Macieira wrote:
That said, back in 2012 when we were discussing the renaming, I made the
argument that some of our binary executables are not build tools but are
instead user applications. Those should not be installed in a
On Monday 19 January 2015 00:16:48 Kevin Kofler wrote:
Thiago Macieira wrote:
Because we're in 2014. Qt 4.0 was released in 2005 and the binary wasn't
renamed. Software is supposed to work with the official version too and
there are 9 years of history of us releasing qmake.
Therefore,
On Monday 19 January 2015 15:18:41 Lisandro Damián Nicanor Pérez Meyer wrote:
Distributors are going a great job creating Qt packages. But not everyone
is using their distro's Qt. In fact, looking at our customers I'd say that
most of them have their own Qt install somewhere on their disk.
On Monday 19 January 2015 19:30:46 Thiago Macieira wrote:
[snip]
So, as Sune Vuorela also explained, having multiple major versions of Qt
in
parallel is always going to be a fact of life.
Indeed, but the Qt devs' original proposal was to simply put it outside
/usr/bin, possibly even
Thiago Macieira wrote:
And like I said, Fedora's and RHEL's refusal to follow the recommendation
is their own problem. You get to pick the pieces from what you broke.
As an additional data point, openSUSE is also shipping qmake as qmake-qt5,
and as far as I can tell, they do not even have
On Sunday 18 January 2015 18:06:45 Lisandro Damián Nicanor Pérez Meyer wrote:
If I'm wrong then simply unmasking qdbus with qtchooser should be enough.
/usr/bin/qdbus should be provided by the default version (qt4's one in our
case) and we might even let qt5-qdbus depend upon it's qt4
Thiago Macieira wrote:
That logic is inverted. It needs to try qmake first because it might be a
more recent version, installed by a binary from the Qt Project, since we
don't rename. Any qmake-qt4 tool, if present, is an older version from the
distribution.
The only thing I promised is that
On Monday 19 January 2015 18:46:18 Thiago Macieira wrote:
[snip]
As for Designer, the discussion in 2012 was that its output is compatible
with Qt 4 and will remain so, but distributions need to upgrade the plugins
to use Qt 5 instead and we can't be blamed if the plugins break their
On Sun, 18 Jan 2015, 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 from the beginning. All
consider this a meta-reply to the entire thread.
On Sat, Jan 17, 2015 at 11:46:58PM +0100, 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
Thiago Macieira wrote:
On Saturday 17 January 2015 23:46:58 Kevin Kofler wrote:
Therefore, we are NOT shipping qtchooser in Fedora by default, and our
qtchooser package in the online repository (package which we only ship at
all due to the insistence of one individual packager – both I and
On Jan 18, 2015, at 10:24 PM, Kevin Kofler kevin.kof...@chello.at wrote:
Konstantin Ritt wrote:
There is no need for moc/rcc/uic to be suffixed. In fact, they are an
internal build tools invoked by qmake and thus they should normally reside
in libexec dir (or you may query qmake for its
On Jan 18, 2015, at 6:34 AM, Kevin Kofler kevin.kof...@chello.at wrote:
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
On 2015-01-19, Oswald Buddenhagen oswald.buddenha...@theqtcompany.com wrote:
your problem is a self-made one: the attempt to co-install major
versions of everything. this is a linux distro specific problem, and
demanding x-platform upstreams to accept trade-offs to adjust to it is
On Monday 19 January 2015 15:01:20 Harri Porten wrote:
On Sun, 18 Jan 2015, 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
I wrote:
Actually, thinking of it, the right solution for this use case would be to
just qtchooser-wrap qmake-qt5 and use:
qmake-qt5
qmake-qt5 -qt release
qmake-qt5 -qt icc
qmake-qt5 -qt clang
qmake-qt5 -qt mips
qmake-qt5 -qt static
qmake-qt5 -qt 5.1
Or rather:
qmake-qt5
qmake-qt5
Thiago Macieira 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
Actually, thinking of it, the right solution for this use case would be to
I'll try to summarize my points of view on this issue as I have been
maintaining qtchooser almost since the beginning. Please bear in mind that
most of what I write here is with the experience gained during this time, had
I know it when the issue arose here in the mailing list I would have
2015-01-18 22:02 GMT+04:00 Lisandro Damián Nicanor Pérez
perezme...@gmail.com:
On Sunday 18 January 2015 21:08:24 Konstantin Ritt wrote:
[snip]
for pretty much ANY build system out there.
There is no need for moc/rcc/uic to be suffixed. In fact, they are an
internal build tools
On Sunday 18 January 2015 21:08:24 Konstantin Ritt wrote:
[snip]
for pretty much ANY build system out there.
There is no need for moc/rcc/uic to be suffixed. In fact, they are an
internal build tools invoked by qmake and thus they should normally reside
in libexec dir (or you may query
2015-01-18 9:56 GMT+04:00 Kevin Kofler kevin.kof...@chello.at:
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
Thiago Macieira wrote:
Because we're in 2014. Qt 4.0 was released in 2005 and the binary wasn't
renamed. Software is supposed to work with the official version too and
there are 9 years of history of us releasing qmake.
Therefore, that buildsystem needs to try qmake alone.
The point is, try
Lisandro Damián Nicanor Pérez Meyer wrote:
With my distro-packager hat on I realize the best solution would have been
indeed using prefixed binaries
Please make them suffixed (*-qt5), which is the established convention.
(Debian also used *-qt4 suffixes in the days where you shipped Qt 3 and 4
On Sunday 18 January 2015 22:48:45 Kevin Kofler wrote:
Lisandro Damián Nicanor Pérez Meyer wrote:
With my distro-packager hat on I realize the best solution would have been
indeed using prefixed binaries
Please make them suffixed (*-qt5), which is the established convention.
(Debian also
On Sunday 18 January 2015 22:17:24 Kevin Kofler wrote:
Lisandro Damián Nicanor Pérez Meyer wrote:
No, there's also qdbus for instance. We in Debian had some problems when
users managed to get a qt4 program using qt5's qdbus by setting
qtchooser's default at qt5. The good side of this: it
Thiago Macieira wrote:
This, Qt 3 software do qmake. Qt 4 software do qmake -v to determine
which version it is: if they found Qt 3, they try qmake-qt4. All of this
is already implemented and was in place before 2012.
Why would they need to try running anything? Just use qmake-qt4 if it
Lisandro Damián Nicanor Pérez Meyer wrote:
On Sunday 18 January 2015 18:06:45 you wrote:
[snip]
If I'm wrong then simply unmasking qdbus with qtchooser should be enough.
/usr/bin/qdbus should be provided by the default version (qt4's one in
our case) and we might even let qt5-qdbus depend
On Sunday 18 January 2015 23:13:30 Kevin Kofler wrote:
Thiago Macieira wrote:
This, Qt 3 software do qmake. Qt 4 software do qmake -v to determine
which version it is: if they found Qt 3, they try qmake-qt4. All of this
is already implemented and was in place before 2012.
Why would they
On Sunday 18 January 2015 06:56:28 Kevin Kofler wrote:
The issues are:
* conceptual: Choosing a Qt version ought to be:
- the job of the software being built (i.e., its build system(*)), whose
developer knows what version of Qt is needed, not the job of the user
building the
On Sunday 18 January 2015 15:02:21 Lisandro Damián Nicanor Pérez Meyer wrote:
No, there's also qdbus for instance. We in Debian had some problems when
users managed to get a qt4 program using qt5's qdbus by setting
qtchooser's default at qt5. The good side of this: it turned out to be a
bug
On Sunday 18 January 2015 12:39:32 Thiago Macieira wrote:
On Sunday 18 January 2015 15:02:21 Lisandro Damián Nicanor Pérez Meyer
wrote:
No, there's also qdbus for instance. We in Debian had some problems when
users managed to get a qt4 program using qt5's qdbus by setting
qtchooser's
On Sunday 18 January 2015 18:06:45 you wrote:
[snip]
And we can't even upstream those patches because on platforms other than
Linux there is no qtchooser available
That would be available *and* enforced.
--
Simulations are not data. In God we trust, all the others must supply data.
Walter
Lisandro Damián Nicanor Pérez Meyer wrote:
No, there's also qdbus for instance. We in Debian had some problems when
users managed to get a qt4 program using qt5's qdbus by setting
qtchooser's default at qt5. The good side of this: it turned out to be a
bug in qt5's qdbus which got fixed and
On Sunday 18 January 2015 18:06:45 you wrote:
[snip]
If I'm wrong then simply unmasking qdbus with qtchooser should be enough.
/usr/bin/qdbus should be provided by the default version (qt4's one in our
case) and we might even let qt5-qdbus depend upon it's qt4 version, so
packages depending on
Thiago Macieira wrote:
That said, back in 2012 when we were discussing the renaming, I made the
argument that some of our binary executables are not build tools but are
instead user applications. Those should not be installed in a private
libexec dir, but should be global in /usr/bin and not
Konstantin Ritt wrote:
There is no need for moc/rcc/uic to be suffixed. In fact, they are an
internal build tools invoked by qmake and thus they should normally reside
in libexec dir (or you may query qmake for its specific libexec dir path
to invoke them manually) -- just like GCC's cc1 or
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
2015-01-18 4:46 GMT+04:00 Kevin Kofler kevin.kof...@chello.at:
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
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
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 Fedora
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
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 in
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.
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
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
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:
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
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.conf
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 subtly
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
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:
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 build
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
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 could install all those
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 requests
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
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 from
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
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 the end
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
distributions'
92 matches
Mail list logo
