#1745 closed enhancement (fixed)
readline-5.1.004
| Reported by: | Matthew Burgess | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | 6.2 |
| Component: | Book | Version: | SVN |
| Severity: | normal | Keywords: | |
| Cc: |
Description
Two new patches are available upstream (http://ftp.gnu.org/gnu/readline/readline-5.1-patches/)
Change History (4)
comment:1 by , 18 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:2 by , 18 years ago
Continuing to update the bash/readline patches is no different than tracking CVS. Any package that has a critical bug in it with a fix in CVS generally mandates a backported patch, but all the little tweaks and fixes do not. I'm not saying these patches are trivial, as I don't know enough about the individual problems to make a call either way, but in 3 months time a whole lot of patches have been generated by upstream and the likelihood of hitting these problems is dropping significantly as judged by the amount of time it is taking for someone to trigger them and report on it. This is just a food for thought comment. Take it as you wish.
comment:3 by , 18 years ago
Archaic,
if we really go with this "unlikely to hit problems, let's ignore upstream fixes" route, the book will become inconsistent. The UTF-8 patch does include all available ncurses fixes for the time of submission. Let's rip them out, as nobody will hit them?
Really, achieving simplicity by not backporting upstream fixes is incompatible with UTF-8 in the book.
comment:4 by , 18 years ago
I really don't understand stand how you surmised my goal as being simplicity. The key phrase was "critical bug". The community backed the establishment of UTF-8 compatability. From that point on, anything that was needed to make a package work for UTF-8 without regression (including swapping out packages and adding packages) instantly fell into the "critical bug" arena. From what I could tell, many of the bash patches were cosmetic. The memory errors were indeed worse. The breaking of the grep testsuite was really bad, too. So obviously some of the patches are necessary, and the inclusion of all patches up to a patch we need would be apropo. However, bash will keep patching away, and most of it will be cosmetic, so why should we add those patches? If patch # 50 comes out that fixes a critical bug, then by all means it would make sense to include the 1st 49 patches as that is what patch 50 should have been tested against. But until a critical patch is released, 20-49 (merely an example) need not be applied by the book. This is consistency with the book, not the other way around. Otherwise every package would have several upstream patches applied in the book.
Let's look at shadow. The loss of su -c functionality is what most would call a "critical bug" so a backport is in order unless the promised new release is indeed just around the corner. However, shadow CVS has undergone more changes than just that since the release of 4.0.14 yet no one suggested backporting *all* the changes, and if someone did suggest it, it is highly unlikely that it would happen because it isn't critical. Bash has had multiple line wrapping problems at the prompt since 2.03 at least. It doesn't keep it from working, it just looks ugly. Obviously not a "critical bug".
Anyway, I hope this clears up any confusion on my rationale. Simplicity just wasn't a part of my thought process here. The question of whether we should be tracking a (for all intents and purposes) CVS snapshot to fix minor niggles was what I was focusing on.
Fixed in r7439.