[Development] Qt modules missing mandatory LICENSE files

[Knoll Lars]

On 2/15/13 1:06 PM, "Stephen Kelly" <stephen.kelly at kdab.com> wrote:

>On Friday, February 15, 2013 11:52:40 Paul Olav Tvete wrote:
>> On Friday 15 February 2013 11:43:10 Stephen Kelly wrote:
>> > On Friday, February 15, 2013 12:28:32 Timo Jyrinki wrote:
>> > > At least qtpim, qtsystems, qtconnectivity, qtfeedback
>> > > and qtwayland will follow later, and I'll be filing change proposals
>> > > for them at that time as part of the process.
>> > 
>> > I don't know why you're packaging those.
>> > 
>> > You understand that they are not 'part of Qt 5', right?
>> > 
>> > And you understand that they are not stable in any way and their API
>>will
>> > likely change, and they will not be part of Qt 5.1, and they may
>>never be
>> > part of a Qt release?
>> 
>> AFAIK, QtWayland is planned to be part of Qt 5.1. (Parts of the module
>>will
>> be marked as experimental.)
>
>It doesn't seem to be in the list Lars posted a few days ago. If you want
>it 
>in 5.1, you should maybe raise that.
>
>Regarding the packages, my concern is labelling and (packagers and users
>of 
>the packages) mistakenly thinking that something is 'part of Qt 5'. The
>ones 
>which are not part of Qt 5 should not imply that they are.
>
>If the qtbase tarball is made into the libqtbase5 package, the qtpim
>tarball 
>should not be made into libqtpim5, and any qt5 metapackage should not
>depend 
>on the qtpim package.
>
>The reason is that those modules are not 'part of Qt 5'. They are no more
>a 
>part of Qt than qlogger, to take a random playground example. The repos
>can't 
>be renamed to have 'playground' in the name, but those modules are not
>really 
>any different to playground modules.

Having the packages on Ubuntu (or any other distribution) is not per se a
bad thing. It turns into a bad thing only if these packages are not
labelled as experimental/unstable by some means.

So I'd like to ask all packagers that package up these to make sure they
are marked accordingly. These packages are very likely to change in a
binary incompatible way going forward and no guarantees are given for them.

Cheers,
Lars