Bug#1019335: Reconsider the egrep and fgrep deprecation
Hi, On 09-09-2022 23:05, Christoph Berg wrote: Re: Santiago Ruano Rincón Changes are ready. I'll upload on Monday. Thanks! Indeed. Thanks. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1019335: Reconsider the egrep and fgrep deprecation
Re: Santiago Ruano Rincón > Changes are ready. I'll upload on Monday. Thanks! Christoph
Bug#1019335: Reconsider the egrep and fgrep deprecation
Control: tags -1 + pending Changes are ready. I'll upload on Monday. signature.asc Description: PGP signature
Bug#1019335: Reconsider the egrep and fgrep deprecation
El 07/09/22 a las 21:13, Paul Gevers escribió: > Hi all, > > For transparency I'm letting you know that, with my Release Team manager hat > on, I have just added a migration block on grep. > > On Wed, 7 Sep 2022 17:39:45 +0200 Santiago Ruano =?iso-8859-1?Q?Rinc=F3n?= > wrote: > > For the moment, I am waiting for (a final) upstream input about those > > warning, in this bug: > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57604 > > > > But giving: > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49996 > > I doubt they are willing to reconsider deprecating egrep and fgrep. > > But we should be considering our own users. Yes. I just wanted to have more info from upstream. Or avoid uploading two releases if they decided to revert that change. > I'd appreciate it if either > Debian continues to ship egrep and fgrep. Or if you don't want to do that or > if you don't want to decide on your own I'd appreciate it if we had a bit of > discussion in a broader audience (I suggest debian-de...@l.do) to see what > we as a project believe is the right course of action. I don't think it is needed to discuss at a debian-devel level. I am reconsidering to revert the related changes. I hope I will be able to upload tomorrow. > > To be clear, I'm not saying we can't have this change at all, but I'm saying > we can't have this change with at least some agreement that it's acceptable > by the project. The block is to buy us time to reach that agreement. > Thanks! > Paul signature.asc Description: PGP signature
Bug#1019335: Reconsider the egrep and fgrep deprecation
Hi all, For transparency I'm letting you know that, with my Release Team manager hat on, I have just added a migration block on grep. On Wed, 7 Sep 2022 17:39:45 +0200 Santiago Ruano =?iso-8859-1?Q?Rinc=F3n?= wrote: For the moment, I am waiting for (a final) upstream input about those warning, in this bug: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57604 But giving: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49996 I doubt they are willing to reconsider deprecating egrep and fgrep. But we should be considering our own users. I'd appreciate it if either Debian continues to ship egrep and fgrep. Or if you don't want to do that or if you don't want to decide on your own I'd appreciate it if we had a bit of discussion in a broader audience (I suggest debian-de...@l.do) to see what we as a project believe is the right course of action. To be clear, I'm not saying we can't have this change at all, but I'm saying we can't have this change with at least some agreement that it's acceptable by the project. The block is to buy us time to reach that agreement. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1019335: Reconsider the egrep and fgrep deprecation
Hi Christoph, El 07/09/22 a las 16:45, Christoph Berg escribió: > POSIX has these notes: > > RATIONALE > > This grep has been enhanced in an upwards-compatible way to provide the > exact functionality of the historical egrep and fgrep commands as well. It > was the clear intention of the standard developers to consolidate the three > greps into a single command. > > The old egrep and fgrep commands are likely to be supported for many > years to come as implementation extensions, allowing historical applications > to operate unmodified. > > https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/ > > > I don't think there's anything to gain (besides saving 2 filesystem > blocks) by removing egrep and fgrep. > > Christoph > Thanks for filing this bug report. For the moment, I am waiting for (a final) upstream input about those warning, in this bug: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57604 But giving: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49996 I doubt they are willing to reconsider deprecating egrep and fgrep. Cheers, -- Santiago signature.asc Description: PGP signature
Bug#1019335: Reconsider the egrep and fgrep deprecation
POSIX has these notes: RATIONALE This grep has been enhanced in an upwards-compatible way to provide the exact functionality of the historical egrep and fgrep commands as well. It was the clear intention of the standard developers to consolidate the three greps into a single command. The old egrep and fgrep commands are likely to be supported for many years to come as implementation extensions, allowing historical applications to operate unmodified. https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/ I don't think there's anything to gain (besides saving 2 filesystem blocks) by removing egrep and fgrep. Christoph
Bug#1019335: Reconsider the egrep and fgrep deprecation
Package: grep Version: 3.8-1 Severity: normal Hi, I see egrep and fgrep have started throwing deprecation warnings: $ egrep egrep: warning: egrep is obsolescent; using grep -E I understand that they have been dubbed deprecated for quite a while: (manpage of an older grep version) In addition, the variant programs egrep, fgrep and rgrep are the same as grep -E, grep -F, and grep -r, respectively. These variants are deprecated, but are provided for backward compatibility. This deprecation will need a LOT of effort to weed out in probably 1000s of packages, while in practise we'll likely never be able to really remove them from the package since users will expect egrep and fgrep to be present on any normal unix system, both for interactive use and to be able to execute 3rd party sh scripts. I suggest removing the deprecation notices, and keep egrep and fgrep around indefinitely. (On a side node, the deprecation notice quoted above also mentions "rgrep", which is no longer mentioned in the manpage, but it's still there in the package, not throwing a deprecation warning.) Christoph
