Message ID | 1347107325-4163-13-git-send-email-francois.perrad@gadz.org |
---|---|
State | Superseded |
Headers | show |
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
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
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
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
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
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.
Signed-off-by: Francois Perrad <francois.perrad@gadz.org> --- package/microperl/Config.in | 1 + 1 file changed, 1 insertion(+)