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
> > duplic
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 quinta-feira, 1 de novembro de 2012 13.12.14, Thiago Macieira wrote:
> > the question is only whether we go the whole nine yards or stop halfway
> > through. if we stop, the configure command line will be -prefix /usr
> > -bindir /usr/lib/$arch/qt5/bin, which isn't exactly the pinnacle of
> > be
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, /usr/lib/i38
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 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_B
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 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
> > unversion
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 a
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 qma
On Thu, Nov 1, 2012 at 4:47 PM, Knoll Lars wrote:
>
> On Oct 30, 2012, at 9:47 PM, Thiago Macieira
> 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 confirmation on that as well as the
> > wi
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
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 wrote:
> 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 enviro
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 t
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
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//b
On Thu, Nov 1, 2012 at 10:56 AM, Thiago Macieira
wrote:
> 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:
> >
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 major/
Hi,
On Wed, Oct 31, 2012 at 8:17 PM, Sune Vuorela wrote:
> On 2012-10-30, Thiago Macieira 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
> >
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
>
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 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 its
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 probl
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 disk
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 c
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 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 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 2012-10-31, Poenitz Andre 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 matter what the offi
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 /
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 a
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
> Qt4-incompat
> -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
> may
Sune Vuorela:
> This is something that will happen to be done. and for the sake of
> documentation and support, please let it be consistant not only across
> distributions, but also across platforms so that documentations don't
> have to be
> if mac | upstream-provided-linux-builds {
> run qmake
On 2012-10-30, Thiago Macieira 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 engines and the meanings
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
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:
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
> ap
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 variable
39 matches
Mail list logo
