[Buildroot] [PATCH 2/3] qt5base: reorder patches

[Buildroot] [PATCH 2/3] qt5base: reorder patches

[Julien CORJON]

Signed-off-by: Julien Corjon <corjon.j@ecagroup.com>
---
 .../qt5/qt5base/{0003-mkspecs-files.patch => 0002-mkspecs-files.patch}    | 0
 .../qt5/qt5base/{0004-xcb-egl-fixes.patch => 0003-xcb-egl-fixes.patch}    | 0
 ...nker-for-host-build.patch => 0004-no-gold-linker-for-host-build.patch} | 0
 ...entfd-for-uclibc.patch => 0005-forkd-disable-eventfd-for-uclibc.patch} | 0
 4 files changed, 0 insertions(+), 0 deletions(-)
 rename package/qt5/qt5base/{0003-mkspecs-files.patch => 0002-mkspecs-files.patch} (100%)
 rename package/qt5/qt5base/{0004-xcb-egl-fixes.patch => 0003-xcb-egl-fixes.patch} (100%)
 rename package/qt5/qt5base/{0005-no-gold-linker-for-host-build.patch => 0004-no-gold-linker-for-host-build.patch} (100%)
 rename package/qt5/qt5base/{0008-forkd-disable-eventfd-for-uclibc.patch => 0005-forkd-disable-eventfd-for-uclibc.patch} (100%)

diff --git a/package/qt5/qt5base/0003-mkspecs-files.patch b/package/qt5/qt5base/0002-mkspecs-files.patch
similarity index 100%
rename from package/qt5/qt5base/0003-mkspecs-files.patch
rename to package/qt5/qt5base/0002-mkspecs-files.patch
diff --git a/package/qt5/qt5base/0004-xcb-egl-fixes.patch b/package/qt5/qt5base/0003-xcb-egl-fixes.patch
similarity index 100%
rename from package/qt5/qt5base/0004-xcb-egl-fixes.patch
rename to package/qt5/qt5base/0003-xcb-egl-fixes.patch
diff --git a/package/qt5/qt5base/0005-no-gold-linker-for-host-build.patch b/package/qt5/qt5base/0004-no-gold-linker-for-host-build.patch
similarity index 100%
rename from package/qt5/qt5base/0005-no-gold-linker-for-host-build.patch
rename to package/qt5/qt5base/0004-no-gold-linker-for-host-build.patch
diff --git a/package/qt5/qt5base/0008-forkd-disable-eventfd-for-uclibc.patch b/package/qt5/qt5base/0005-forkd-disable-eventfd-for-uclibc.patch
similarity index 100%
rename from package/qt5/qt5base/0008-forkd-disable-eventfd-for-uclibc.patch
rename to package/qt5/qt5base/0005-forkd-disable-eventfd-for-uclibc.patch
-- 
2.1.0

[Buildroot] [PATCH 3/3] qt5quick1, qt5script, qt5webkit: tag as deprecated

[Julien CORJON]

Signed-off-by: Julien Corjon <corjon.j@ecagroup.com>
---
 package/qt5/Config.in                    | 9 +++++----
 package/qt5/qt5quick1/Config.in          | 6 +++++-
 package/qt5/qt5script/Config.in          | 6 +++++-
 package/qt5/qt5webkit-examples/Config.in | 6 +++++-
 package/qt5/qt5webkit/Config.in          | 6 +++++-
 5 files changed, 25 insertions(+), 8 deletions(-)

diff --git a/package/qt5/Config.in b/package/qt5/Config.in
index e8ec7d9..49e3450 100644
--- a/package/qt5/Config.in
+++ b/package/qt5/Config.in
@@ -36,15 +36,16 @@ source "package/qt5/qt5enginio/Config.in"
 source "package/qt5/qt5graphicaleffects/Config.in"
 source "package/qt5/qt5imageformats/Config.in"
 source "package/qt5/qt5multimedia/Config.in"
-source "package/qt5/qt5quick1/Config.in"
 source "package/qt5/qt5quickcontrols/Config.in"
-source "package/qt5/qt5script/Config.in"
 source "package/qt5/qt5sensors/Config.in"
 source "package/qt5/qt5serialport/Config.in"
 source "package/qt5/qt5svg/Config.in"
-source "package/qt5/qt5webkit/Config.in"
-source "package/qt5/qt5webkit-examples/Config.in"
 source "package/qt5/qt5websockets/Config.in"
 source "package/qt5/qt5x11extras/Config.in"
 source "package/qt5/qt5xmlpatterns/Config.in"
+comment "Depracated Qt modules"
+source "package/qt5/qt5quick1/Config.in"
+source "package/qt5/qt5script/Config.in"
+source "package/qt5/qt5webkit/Config.in"
+source "package/qt5/qt5webkit-examples/Config.in"
 endif
diff --git a/package/qt5/qt5quick1/Config.in b/package/qt5/qt5quick1/Config.in
index 16076eb..8cde603 100644
--- a/package/qt5/qt5quick1/Config.in
+++ b/package/qt5/qt5quick1/Config.in
@@ -1,5 +1,5 @@
 config BR2_PACKAGE_QT5QUICK1
-	bool "qt5quick1"
+	bool "qt5quick1 (deprecated)"
 	select BR2_PACKAGE_QT5BASE
 	select BR2_PACKAGE_QT5BASE_GUI
 	select BR2_PACKAGE_QT5BASE_NETWORK
@@ -15,6 +15,10 @@ config BR2_PACKAGE_QT5QUICK1
 
 	  This package corresponds to the qt5quick1 module.
 
+	  This package has been tagged as deprecated since version
+	  5.5.0 and should be replaced by Qt Quick module in new
+	  design.
+
 	  http://qt.io
 
 comment "qt5quick1 needs a toolchain w/ dynamic library"
diff --git a/package/qt5/qt5script/Config.in b/package/qt5/qt5script/Config.in
index 5313e90..447ac86 100644
--- a/package/qt5/qt5script/Config.in
+++ b/package/qt5/qt5script/Config.in
@@ -1,5 +1,5 @@
 config BR2_PACKAGE_QT5SCRIPT
-	bool "qt5script"
+	bool "qt5script (deprecated)"
 	select BR2_PACKAGE_QT5BASE
 	depends on BR2_PACKAGE_QT5_JSCORE_AVAILABLE
 	help
@@ -8,4 +8,8 @@ config BR2_PACKAGE_QT5SCRIPT
 
 	  This package corresponds to the qt5script module.
 
+	  This package has been tagged as deprecated since version
+	  5.5.0 and should be replaced by Qt QML module in new
+	  design.
+
 	  http://qt.io
diff --git a/package/qt5/qt5webkit-examples/Config.in b/package/qt5/qt5webkit-examples/Config.in
index e7610c2..5267f9d 100644
--- a/package/qt5/qt5webkit-examples/Config.in
+++ b/package/qt5/qt5webkit-examples/Config.in
@@ -1,5 +1,5 @@
 config BR2_PACKAGE_QT5WEBKIT_EXAMPLES
-	bool "qt5webkit examples"
+	bool "qt5webkit examples (deprecated)"
 	depends on BR2_PACKAGE_QT5WEBKIT
 	help
 	  Qt is a cross-platform application and UI framework for
@@ -7,4 +7,8 @@ config BR2_PACKAGE_QT5WEBKIT_EXAMPLES
 
 	  This package contains examples for the qt5webkit module.
 
+	  This package has been tagged as deprecated since version
+	  5.5.0 and should be replaced by Qt WebEngine module in
+	  new design.
+
 	  http://qt.io
diff --git a/package/qt5/qt5webkit/Config.in b/package/qt5/qt5webkit/Config.in
index 3507a9d..df69c5f 100644
--- a/package/qt5/qt5webkit/Config.in
+++ b/package/qt5/qt5webkit/Config.in
@@ -1,5 +1,5 @@
 config BR2_PACKAGE_QT5WEBKIT
-	bool "qt5webkit"
+	bool "qt5webkit (depracated)"
 	select BR2_PACKAGE_QT5BASE
 	select BR2_PACKAGE_QT5BASE_ICU
 	select BR2_PACKAGE_QT5BASE_GUI
@@ -17,4 +17,8 @@ config BR2_PACKAGE_QT5WEBKIT
 
 	  This package corresponds to the qt5webkit module.
 
+	  This package has been tagged as deprecated since version
+	  5.5.0 and should be replaced by Qt WebEngine module in
+	  new design.
+
 	  http://qt.io
-- 
2.1.0

[Buildroot] [PATCH 3/3] qt5quick1, qt5script, qt5webkit: tag as deprecated

[Thomas Petazzoni]

Julien,

On Fri, 3 Jul 2015 07:20:54 +0000, Julien CORJON wrote:

> diff --git a/package/qt5/Config.in b/package/qt5/Config.in
> index e8ec7d9..49e3450 100644
> --- a/package/qt5/Config.in
> +++ b/package/qt5/Config.in
> @@ -36,15 +36,16 @@ source "package/qt5/qt5enginio/Config.in"
>  source "package/qt5/qt5graphicaleffects/Config.in"
>  source "package/qt5/qt5imageformats/Config.in"
>  source "package/qt5/qt5multimedia/Config.in"
> -source "package/qt5/qt5quick1/Config.in"
>  source "package/qt5/qt5quickcontrols/Config.in"
> -source "package/qt5/qt5script/Config.in"
>  source "package/qt5/qt5sensors/Config.in"
>  source "package/qt5/qt5serialport/Config.in"
>  source "package/qt5/qt5svg/Config.in"
> -source "package/qt5/qt5webkit/Config.in"
> -source "package/qt5/qt5webkit-examples/Config.in"
>  source "package/qt5/qt5websockets/Config.in"
>  source "package/qt5/qt5x11extras/Config.in"
>  source "package/qt5/qt5xmlpatterns/Config.in"
> +comment "Depracated Qt modules"

Deprecated

but I don't think it's really worth to have them in a separate part of
the menu, since all of them already have a "(deprecated)" indication in
their prompt.

However, I'm wondering if we should not simply make them depend on
BR2_DEPRECATED_SINCE_2015_08. But that will make them disappear
completely by default, unless the user enables BR2_DEPRECATED.

Actually, our deprecation/removal process is a bit weird: deprecated
should be a smoother thing than removal. But in practice, when we
deprecate something by making it 'depends on
BR2_DEPRECATED_SINCE_YYYY_MM', it gets automatically removed from your
configuration without any notification (unless you enable manually
BR2_DEPRECATED, of course). While if we remove it entirely, we add it
to Config.in.legacy, and the users upgrading get a clear notification.

So users are better notified of removals than deprecations.

Arnout, what do you think about this?

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 3/3] qt5quick1, qt5script, qt5webkit: tag as deprecated

[Julien CORJON]

Thomas,

Le 03/07/2015 09:43, Thomas Petazzoni a ?crit :
> Julien,
>
> On Fri, 3 Jul 2015 07:20:54 +0000, Julien CORJON wrote:
>
>> diff --git a/package/qt5/Config.in b/package/qt5/Config.in
...
>> +comment "Depracated Qt modules"
>
> Deprecated

Will be fix in a V2.

>
> but I don't think it's really worth to have them in a separate part of
> the menu, since all of them already have a "(deprecated)" indication in
> their prompt.

I'm ok with that

>
> However, I'm wondering if we should not simply make them depend on
> BR2_DEPRECATED_SINCE_2015_08. But that will make them disappear
> completely by default, unless the user enables BR2_DEPRECATED.
>
> Actually, our deprecation/removal process is a bit weird: deprecated
> should be a smoother thing than removal. But in practice, when we
> deprecate something by making it 'depends on
> BR2_DEPRECATED_SINCE_YYYY_MM', it gets automatically removed from your
> configuration without any notification (unless you enable manually
> BR2_DEPRECATED, of course). While if we remove it entirely, we add it
> to Config.in.legacy, and the users upgrading get a clear notification.
>
> So users are better notified of removals than deprecations.
>
> Arnout, what do you think about this?

For now Qt tag these 3 modules as deprecated but they did not reach the 
end of life.

In my opinion, users who start a new design should be informed that in 
the near future these modules will not be supported anymore when user 
who need to bump Qt for they existing design (as we do) should be able 
to do that without loosing they already existing configuration.

For these reasons I don't think we should use 
BR2_DEPRECATED_SINC_YYYY_MM neither add them to Config.in.legacy since 
this is not a Buildroot issue but a Qt one.

At the end, when Qt will stop provide these module, we should add them 
to Config.in.legacy.

>
> Thomas
>

-- 
Regards,

Julien Corjon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: corjon_j.vcf
Type: text/x-vcard
Size: 428 bytes
Desc: corjon_j.vcf
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20150703/c9010935/attachment.vcf>

[Buildroot] [PATCH 3/3] qt5quick1, qt5script, qt5webkit: tag as deprecated

[Arnout Vandecappelle]

On 07/03/15 10:55, Julien CORJON wrote:
> 
> Thomas,
> 
> Le 03/07/2015 09:43, Thomas Petazzoni a ?crit :
[snip]
>> However, I'm wondering if we should not simply make them depend on
>> BR2_DEPRECATED_SINCE_2015_08. But that will make them disappear
>> completely by default, unless the user enables BR2_DEPRECATED.
>>
>> Actually, our deprecation/removal process is a bit weird: deprecated
>> should be a smoother thing than removal. But in practice, when we
>> deprecate something by making it 'depends on
>> BR2_DEPRECATED_SINCE_YYYY_MM', it gets automatically removed from your
>> configuration without any notification (unless you enable manually
>> BR2_DEPRECATED, of course). While if we remove it entirely, we add it
>> to Config.in.legacy, and the users upgrading get a clear notification.
>>
>> So users are better notified of removals than deprecations.
>>
>> Arnout, what do you think about this?

 Good point indeed. But I don't see a simple solution. We could use the same
approach as for legacy (selecting a symbol and printing a big fat warning
comment), but then it's easy for a user to accidentally select one of the
deprecated options, and that's exactly what we want to avoid.

 So we'd have to look for things like temporarily enabling
BR2_DEPRECATED_SINCE_* through the environment when 'make oldconfig' is run, or
when one of the deprecated packages was selected before you do 'make
menuconfig', but not when you do 'make menuconfig' from the beginning. It
quickly becomes pretty dirty... Something for Yann, perhaps :-)

> 
> For now Qt tag these 3 modules as deprecated but they did not reach the 
> end of life.
> 
> In my opinion, users who start a new design should be informed that in 
> the near future these modules will not be supported anymore when user 
> who need to bump Qt for they existing design (as we do) should be able 
> to do that without loosing they already existing configuration.

 +1 to that. In fact, qt5quick1 and qt5script are both compatibility layers for
qt4 legacy, just like BR2_PACKAGE_QT_QT3SUPPORT. So they were 'deprecated' from
the beginning. So instead of (deprecated), perhaps (legacy compatibility) is a
better tag.

 But that doesn't really fit with our rule of thumb that menu entries should be
just the package name. Therefore, I'm more in favour of moving this stuff in a
separate area with a comment delimiter as Julien originally proposed. But then
without the (deprecated) tag.


 Regards,
 Arnout

> 
> For these reasons I don't think we should use 
> BR2_DEPRECATED_SINC_YYYY_MM neither add them to Config.in.legacy since 
> this is not a Buildroot issue but a Qt one.
> 
> At the end, when Qt will stop provide these module, we should add them 
> to Config.in.legacy.
> 
>>
>> Thomas
>>
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF