Patchwork [13/13] microperl: mark as DEPRECATED

login
register
mail settings
Submitter Francois Perrad
Date Sept. 8, 2012, 12:28 p.m.
Message ID <1347107325-4163-13-git-send-email-francois.perrad@gadz.org>
Download mbox | patch
Permalink /patch/182568/
State Superseded
Headers show

Comments

Francois Perrad - Sept. 8, 2012, 12:28 p.m.
Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
---
 package/microperl/Config.in |    1 +
 1 file changed, 1 insertion(+)
Thomas Petazzoni - Sept. 20, 2012, 8:22 p.m.
Dear Francois Perrad,

On Sat,  8 Sep 2012 14:28:45 +0200, Francois Perrad wrote:
> Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
> ---
>  package/microperl/Config.in |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/package/microperl/Config.in b/package/microperl/Config.in
> index 66bbedd..19d104a 100644
> --- a/package/microperl/Config.in
> +++ b/package/microperl/Config.in
> @@ -2,6 +2,7 @@ config BR2_PACKAGE_MICROPERL
>  	bool "microperl"
>  	# needs fork()
>  	depends on BR2_USE_MMU
> +	depends on BR2_DEPRECATED

If microperl is deprecated, is it really useful to have patches 7, 8,
9, 10, 11 and 12 that are making improvements to it, and updating it to
a more recent version?

Thanks,

Thomas
Francois Perrad - Sept. 21, 2012, 6:53 p.m.
2012/9/20 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
> Dear Francois Perrad,
>
> On Sat,  8 Sep 2012 14:28:45 +0200, Francois Perrad wrote:
>> Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
>> ---
>>  package/microperl/Config.in |    1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/package/microperl/Config.in b/package/microperl/Config.in
>> index 66bbedd..19d104a 100644
>> --- a/package/microperl/Config.in
>> +++ b/package/microperl/Config.in
>> @@ -2,6 +2,7 @@ config BR2_PACKAGE_MICROPERL
>>       bool "microperl"
>>       # needs fork()
>>       depends on BR2_USE_MMU
>> +     depends on BR2_DEPRECATED
>
> If microperl is deprecated, is it really useful to have patches 7, 8,
> 9, 10, 11 and 12 that are making improvements to it, and updating it to
> a more recent version?
>

Thomas,

I added this commit after your request in
http://patchwork.ozlabs.org/patch/180227/ (Aug. 27, 2012, 9:54 p.m.)

François


> Thanks,
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
> _______________________________________________
> buildroot mailing list
> buildroot@busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
Thomas Petazzoni - Sept. 21, 2012, 6:59 p.m.
Dear François Perrad,

On Fri, 21 Sep 2012 20:53:08 +0200, François Perrad wrote:

> I added this commit after your request in
> http://patchwork.ozlabs.org/patch/180227/ (Aug. 27, 2012, 9:54 p.m.)

Yes, I perfectly remember asking you to mark microperl as deprecated,
since you were saying that microperl was a dead-end. My question here
is different: knowing that microperl is deprecated, why would we bother
bumping its version, making fixes and so on? It doesn't look really
interesting to write patches against deprecated and even less
interesting to review such patches :-)

Thomas
Francois Perrad - Sept. 23, 2012, 3:11 p.m.
2012/9/21 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
> Dear François Perrad,
>
> On Fri, 21 Sep 2012 20:53:08 +0200, François Perrad wrote:
>
>> I added this commit after your request in
>> http://patchwork.ozlabs.org/patch/180227/ (Aug. 27, 2012, 9:54 p.m.)
>
> Yes, I perfectly remember asking you to mark microperl as deprecated,
> since you were saying that microperl was a dead-end. My question here
> is different: knowing that microperl is deprecated, why would we bother
> bumping its version, making fixes and so on? It doesn't look really
> interesting to write patches against deprecated and even less
> interesting to review such patches :-)
>

Today, 5 packages depend on microperl :
    autoconf
    automake
    ntp
    samba
    libxml-parser-perl (requires only a full host perl)
So, I think that it is not a good idea to remove it (after a deprecation).

François

> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
Thomas Petazzoni - Sept. 23, 2012, 3:25 p.m.
Dear François Perrad,

On Sun, 23 Sep 2012 17:11:56 +0200, François Perrad wrote:

> > Yes, I perfectly remember asking you to mark microperl as
> > deprecated, since you were saying that microperl was a dead-end. My
> > question here is different: knowing that microperl is deprecated,
> > why would we bother bumping its version, making fixes and so on? It
> > doesn't look really interesting to write patches against deprecated
> > and even less interesting to review such patches :-)
> >
> 
> Today, 5 packages depend on microperl :
>     autoconf
>     automake
>     ntp
>     samba
>     libxml-parser-perl (requires only a full host perl)
> So, I think that it is not a good idea to remove it (after a
> deprecation).

Ehh, can't those packages be changed to depend on perl or miniperl
instead of microperl?

I think you still don't get the point I'm making: you have said
yourself that microperl is a dead end, because it is no longer
maintained upstream. Therefore we mark it deprecated, with the idea of
removing it during the next release cycle. For this reason, I don't
think it's worth spending time making more fixes, upgrades and so on on
microperl (which half of your patch series is doing). Is my point
clearer?

Thanks!

Thomas

Patch

diff --git a/package/microperl/Config.in b/package/microperl/Config.in
index 66bbedd..19d104a 100644
--- a/package/microperl/Config.in
+++ b/package/microperl/Config.in
@@ -2,6 +2,7 @@  config BR2_PACKAGE_MICROPERL
 	bool "microperl"
 	# needs fork()
 	depends on BR2_USE_MMU
+	depends on BR2_DEPRECATED
 	help
 	  Perl without operating-specific functions such as readdir.