On Thu, Nov 01, 2012 at 01:12:14PM -0700, Thiago Macieira wrote:
On quinta-feira, 1 de novembro de 2012 20.32.06, Oswald Buddenhagen wrote:
You're asking that they have a different 32-bit package to be installed on
64- bit systems than then 32-bit package to be installed on 32-bit
On sexta-feira, 2 de novembro de 2012 15.11.40, Oswald Buddenhagen wrote:
But we're not installing to the common directory. We're installing to an
arch- specific path, which the existing infrastructure may not be
equipped to handle. So it's entirely possible we'll end up with
duplication
Hi,
after reading through the whole thread, here's my comments on the different
parts:
On Oct 30, 2012, at 9:47 PM, Thiago Macieira thiago.macie...@intel.com wrote:
If I've forgotten anything, please add.
As far as I can tell, here are the pending decisions, in increasing order of
On Wed, Oct 31, 2012 at 08:02:20AM -0700, Thiago Macieira wrote:
On quarta-feira, 31 de outubro de 2012 12.23.27, Oswald Buddenhagen wrote:
3) library versioning (i.e., adding 5 to the library name)
-1
renaming is unnecessary:
- there is no problem at all at run-time
- the
On Thu, Nov 1, 2012 at 4:47 PM, Knoll Lars lars.kn...@digia.com wrote:
On Oct 30, 2012, at 9:47 PM, Thiago Macieira thiago.macie...@intel.com
wrote:
2) QML tool names
Kai raised the point that many of the QML 2 tools work for QML 1 too and
maybe
even for Qt 4's QML 1. We need
On 10/31/12 15:14, Oswald Buddenhagen wrote:
there is no need to make it ignore anything, as -lQtCore would not find
any of the above files. the unversioned symlink would be found by virtue
of adding -L/usr/lib64/qt5/lib to the linker command line, and that
directory (which you get from qmake
On quinta-feira, 1 de novembro de 2012 10.57.59, Oswald Buddenhagen wrote:
Ossi: let me ask you something then: do you want our make install to
manage
both /usr/lib *and* /usr/lib/qt5/lib?
no.
My argument is that the split is necessary because we're being asked to
manage all of this.
On Thu, Nov 01, 2012 at 08:20:02AM -0700, Thiago Macieira wrote:
On quinta-feira, 1 de novembro de 2012 10.57.59, Oswald Buddenhagen wrote:
as pointed out in another mail, this doesn't phaze us a bit - unless
some distro thinks it's wise to override our choice and install an
unversioned
On quinta-feira, 1 de novembro de 2012 08.47.12, Knoll Lars wrote:
4) new installation paths (besides the bin directory)
The latest patch I've provided creates a grouping of all arch-dependent
files in ARCHDATADIR, with arch-independent files in DATADIR. That
change, by itself, is
On quinta-feira, 1 de novembro de 2012 17.13.58, Oswald Buddenhagen wrote:
You MUST provide a set of installation instructions. This is YOUR
proposal,
which we must analyse and compare to mine.
my proposal is very simple: wrap everything in QT_HOST_BINS (which
equals QT_INSTALL_BINS on
On Thu, Nov 01, 2012 at 09:37:22AM -0700, Thiago Macieira wrote:
On quinta-feira, 1 de novembro de 2012 17.13.58, Oswald Buddenhagen wrote:
distributions should have *both*:
/usr/lib/qt5//bin/assistant AND
/usr/lib64/qt5/bin/assistant
On quinta-feira, 1 de novembro de 2012 20.32.06, Oswald Buddenhagen wrote:
You're asking that they have a different 32-bit package to be installed on
64- bit systems than then 32-bit package to be installed on 32-bit
systems. That's a policy change.
last time i looked,
On 10/31/2012 01:06 AM, Thiago Macieira wrote:
In any case, what's the problem with making a subjective decision? Clearly the
applications need to be split in two groups, so why shouldn't the Qt Project
make its recommendation to the downstreams?
I would like that all binaries are installed in
On 2012-10-30, Thiago Macieira thiago.macie...@intel.com wrote:
1) QML environment variables
The variable for import paths has been versioned from QML_IMPORT_PATH to
QML2_IMPORT_PATH. But I have not changed any of the other variables. We need
a
decision from the team familiar with the
-Original Message-
From: development-bounces+kai.koehne=digia@qt-project.org
[mailto:development-bounces+kai.koehne=digia@qt-project.org] On
Behalf Of Thiago Macieira
[...]
2) QML tool names
Kai raised the point that many of the QML 2 tools work for QML 1 too and
maybe even
On Wednesday, October 31, 2012 09:46:18 Alberto Mardegan wrote:
Also consider that if you decide for a split of the binaries, you run
the risk that Qt6 will require a different split (some binary which is
reusable between Qt4 and Qt5 might not be compatible with Qt6, or some
this is just re-iterating stuff, but whatever.
On Tue, Oct 30, 2012 at 01:47:03PM -0700, Thiago Macieira wrote:
1) QML environment variables
+1
2) QML tool names
0
3) library versioning (i.e., adding 5 to the library name)
-1
renaming is unnecessary:
- there is no problem at all at
On 10/31/12 12:23, Oswald Buddenhagen wrote:
renaming is unnecessary:
- there is no problem at all at run-time
- the problem at build time is solved by -L flags. there is no need for
an unversioned symlink in /usr/lib.
On RHEL6, this is how it looks right now:
kundratj@noe2 ~ $ locate
On 2012-10-31, Poenitz Andre andre.poen...@digia.com wrote:
This is not about overriding someone. This is about ranking the user
experience of the majority of users higher than the convenience of a
handful of Linux distribution packagers - half which will do their own
renaming anyway, no
On Wed, Oct 31, 2012 at 01:26:09PM +0100, Jan Kundrát wrote:
On 10/31/12 12:23, Oswald Buddenhagen wrote:
renaming is unnecessary:
- there is no problem at all at run-time
- the problem at build time is solved by -L flags. there is no need for
an unversioned symlink in /usr/lib.
On
On quarta-feira, 31 de outubro de 2012 12.23.27, Oswald Buddenhagen wrote:
3) library versioning (i.e., adding 5 to the library name)
-1
renaming is unnecessary:
- there is no problem at all at run-time
- the problem at build time is solved by -L flags. there is no need for
an
On quarta-feira, 31 de outubro de 2012 09.46.18, Alberto Mardegan wrote:
On 10/31/2012 01:06 AM, Thiago Macieira wrote:
In any case, what's the problem with making a subjective decision? Clearly
the applications need to be split in two groups, so why shouldn't the Qt
Project make its
On Tue, Oct 30, 2012 at 05:06:33PM -0700, Thiago Macieira wrote:
On terça-feira, 30 de outubro de 2012 23.52.08, André Pönitz
wrote:
On Tue, Oct 30, 2012 at 01:47:03PM -0700, Thiago Macieira wrote:
5) executable split between end-user applications and indirect
tooling The most
On quarta-feira, 31 de outubro de 2012 20.31.57, André Pönitz wrote:
And if we define the cut as the ones that have compatibility of
purpose and output, versus the ones that don't?
This sounds not overly wrong as it would reduce some possibly
needless duplication and reduction in diskspace.
On quarta-feira, 31 de outubro de 2012 08.02.20, Thiago Macieira wrote:
On quarta-feira, 31 de outubro de 2012 12.23.27, Oswald Buddenhagen wrote:
3) library versioning (i.e., adding 5 to the library name)
-1
renaming is unnecessary:
- there is no problem at all at run-time
On quarta-feira, 31 de outubro de 2012 12.23.27, Oswald Buddenhagen wrote:
4) new installation paths (besides the bin directory)
The latest patch I've provided creates a grouping of all arch-dependent
files in ARCHDATADIR, with arch-independent files in DATADIR. That
change, by itself, is
On 01/11/12 01:02, Thiago Macieira wrote:
Also, do I understand correctly that you're suggesting that multiarch
distributions should have *both*:
/usr/lib/qt5//bin/assistant AND
/usr/lib64/qt5/bin/assistant
/usr/lib/qt5//bin/linguist AND
On quinta-feira, 1 de novembro de 2012 09.23.37, Lincoln Ramsay wrote:
On 01/11/12 01:02, Thiago Macieira wrote:
Also, do I understand correctly that you're suggesting that multiarch
distributions should have *both*:
/usr/lib/qt5//bin/assistant AND
Hi,
On Wed, Oct 31, 2012 at 8:17 PM, Sune Vuorela nos...@vuorela.dk wrote:
On 2012-10-30, Thiago Macieira thiago.macie...@intel.com wrote:
1) QML environment variables
The variable for import paths has been versioned from QML_IMPORT_PATH to
QML2_IMPORT_PATH. But I have not changed any of
On quinta-feira, 1 de novembro de 2012 10.01.11, Chris Adams wrote:
Regarding QML_IMPORT_PATH, I discussed this yesterday and this morning with
Martin Jones and Andrew den Exter, and a couple of things deserve
mentioning:
1) through the versioning of imports (ie, the path lookup with
On Thu, Nov 1, 2012 at 10:56 AM, Thiago Macieira
thiago.macie...@intel.comwrote:
On quinta-feira, 1 de novembro de 2012 10.01.11, Chris Adams wrote:
Regarding QML_IMPORT_PATH, I discussed this yesterday and this morning
with
Martin Jones and Andrew den Exter, and a couple of things deserve
On 01/11/12 09:41, Thiago Macieira wrote:
On quinta-feira, 1 de novembro de 2012 09.23.37, Lincoln Ramsay wrote:
On 01/11/12 01:02, Thiago Macieira wrote:
Also, do I understand correctly that you're suggesting that multiarch
distributions should have *both*:
/usr/lib/qt5//bin/assistant
On quinta-feira, 1 de novembro de 2012 11.39.22, Chris Adams wrote:
You're right.
Ok, all in all, I think having separate import install paths and separate
envvars to define the import path basedir at runtime is the best solution
after all.
Thanks. That makes my life easier because there's no
On quinta-feira, 1 de novembro de 2012 11.56.25, Lincoln Ramsay wrote:
On 01/11/12 09:41, Thiago Macieira wrote:
On quinta-feira, 1 de novembro de 2012 09.23.37, Lincoln Ramsay wrote:
On 01/11/12 01:02, Thiago Macieira wrote:
Also, do I understand correctly that you're suggesting that
If I've forgotten anything, please add.
As far as I can tell, here are the pending decisions, in increasing order of
severity:
1) QML environment variables
The variable for import paths has been versioned from QML_IMPORT_PATH to
QML2_IMPORT_PATH. But I have not changed any of the other
On Tue, Oct 30, 2012 at 01:47:03PM -0700, Thiago Macieira wrote:
5) executable split between end-user applications and indirect tooling
The most controversial proposal so far is to split the binaries into two
groups: one that gets installed to PREFIX/bin, containing the executables for
On terça-feira, 30 de outubro de 2012 23.52.08, André Pönitz wrote:
On Tue, Oct 30, 2012 at 01:47:03PM -0700, Thiago Macieira wrote:
5) executable split between end-user applications and indirect tooling
The most controversial proposal so far is to split the binaries into two
groups: one
37 matches
Mail list logo
