Stefan Teleman wrote:
>
>
> Darren J Moffat wrote:
>
>> The pkg-config file should be in /usr/lib/pkgconfig we already set
>> precedence for this in other cases. I have no problem with providing
>> multiple pkgconfig files under the path you gave but the canonical
>> version of qt should have one in /usr/lib/pkgconfig
>
> Which version of QT is the "canonical version of qt" ?
>
> 4.4.1 ? 4.5.0 ?
>
> Trolltech makes no claims as to any of QT4's versions being "canonical".
That is for the project team too choose. Just like the project teams
for things like perl, python, mysql and all those other projects that
ship multiple versions often have to.
>>> Or, one can say --with-qt-include=${QTDIR}/include
>>> --with-qt-libs=${QTDIR}/lib
>>
>> $QTDIR isn't defined in my environment.
>
>>>> Is this the common layout on Linux based distributions where GNOME
>>>> is considered the primary desktop rather than KDE ? What is they
>>>> layout when KDE is the primary desktop ?
>>>
>>> SUSE organizes as /usr/lib/qt3 /usr/lib/qt4, etc
>>
>> where are the include files on SUSE ?
>
> In /usr/include, which I believe is inconsistent, and wrong.
Why ? /usr/include is where include files usually live and where they
are looked for by default.
Why are you trying to hide this somewhere else ? We learn't from
/usr/sfw that it only causes pain.
>> Why is your layout better than the SUSE one ? What problems does it
>> solve that their layout doesn't ?
>
> The layout proposed here follows the layout established by the Perl ARC
> Case PSARC/1999/192.
There is a /usr/bin/perl even with that layout, your proposal has no
equivalent.
> I don't know if it's "better" than Linux, I don't particularily consider
> Linux a benchmark for adjudicating the soundness of directory layouts,
> and I prefer following established precedents which have been sanctioned
> and approved by the ARCs.
That is all well and good but don't just copy cases that are 8 years old
think about the environment we are in now.
>>> It can't be Committed because [1] it doesn't really implement any
>>> known Industry standard,
>>
>> That isn't the definition of committed.
>
> http://opensolaris.org/os/community/arc/policies/interface-taxonomy/
>
> It appears to be one of the attributes to be taken into consideration
> when assigning a Committed stability level to an Interface, or a group
> of Interfaces. Given that QT does not implement a known Industry
> Standard, that's strike one against Committed.
It isn't the only one though.
>> > and [2] we don't control QT's Interface Stability level.
>>
>> Then what was all that text above about ? It can be Committed if the
>> project team believes that the upstream behaves in a manner suitable.
>> The text you provided indicates you do think that.
>
> Considering the ABI Micro
> Release Stability guarantee provided by Trolltech ASA, a
> "Committed" Interface Stability Classification would have been
> appropriate.
>
> The project team does not believe that, nor do the ARC Case Documents
> imply that the project team believes that. The ARC Case documents
> clearly states that this ABI stability guarantee is provided by
> Trolltech, and this guarantee only applies to Micro releases.
That to me contracts the very sentence you wrote and just quoted. It
acutally says that Committed would have been appropriate.
> Is an interface stability guarantee which is effective only for Micro
> releases appropriate for "Committed" ? I do not believe that it is. We
> are saying that "QT 4.4.1 will be ABI and API compatible with 4.4.3, but
> not with 4.5.0".
If you ship 4.4.x and 4.5.x at the same time yes.
> This does not qualify for "Committed". That's strike two against Committed.
I disagree but I don't care enough to argue with you about it since in
reality it makes no difference what so ever to how QT will be used.
Leave it at Uncomitted.
--
Darren J Moffat
