Bug 1564789
| Summary: | sed-4.2.2 is 5.5 years old: sed-4.5 has notable improvements | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Jim Meyering <jim> |
| Component: | sed | Assignee: | Jakub Martisko <jamartis> |
| Status: | CLOSED WONTFIX | QA Contact: | qe-baseos-tools-bugs |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.7 | CC: | kdudka |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-04-09 08:04:08 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Jim Meyering
2018-04-07 21:49:54 UTC
Hello Jim, we try to avoid major package upgrades within a single major version of RHEL (mainly to minimize possible incompatibilities with existing scripts), so unless there is some business justification or other important reason, I do not plan to update sed within the RHEL-7 (on the other hand, I've already updated sed to 4.5 in Fedora rawhide). Regards, Jakub Hi Jakub,
I completely understand the general aversion to upgrading anything for RHEL.
However, the only incompatibility is this, from 4.3:
** Feature removal
The "L" command (format a paragraph like the fmt(1) command would)
has been listed in the documentation as a failed experiment for at
least 10 years. That command is now removed.
Did you even know about the "L" command? I didn't :-)
Really stretching the term "incompatibility", one might also include
this from 4.5, though I call this a clear bug fix:
sed now treats the sequence '\x5c' (ASCII 92, backslash) as literal
backslash character, not as an escape prefix character.
[Bug present since sed-3.02.80]
Old behavior:
$ echo z | sed -E 's/(z)/\x5c1/' # identical to 's/(z)/\1/'
z
New behavior:
$ echo z | sed -E 's/(z)/\x5c1/'
\1
If the "L" removal is your only objection, I would be willing to reintroduce it and even consider making a new release just for that.
I agree with Jakub here. Each single bug fix (not only the mentioned one) can potentially break existing scripts that rely on the buggy behavior. Therefore, we do not rebase packages in already released products unless we have a business justification for the rebase. That is the added value of RHEL. Even though many of the changes made during the last five years are clear bug fixes, as Kamil mentioned, we can't be really sure that there are no scripts that depend on the buggy behavior. Out of the top of my head, I would add the bug with handling symlinks and selinux context to the list of incompatibilities you mentioned and I suppose that others could be found. And since the sed is one of the critical components of the system, I really do not want to introduce any (possible) incompatibilities within released RHEL, unless I really have to. Another potential issue: we introduced the DFA matcher. That's what gains the 10x speed-up. But unless the boundary between it and the other matchers is perfect, there could be subtle differences there, too. |