[LFS Trac] #1745: readline-5.1.004

LFS Trac trac at linuxfromscratch.org
Sun Mar 19 20:23:40 PST 2006


#1745: readline-5.1.004
------------------------------------------+---------------------------------
 Reporter:  matthew at linuxfromscratch.org  |        Owner:  lfs-book at linuxfromscratch.org
     Type:  enhancement                   |       Status:  closed                       
 Priority:  normal                        |    Milestone:  6.2                          
Component:  Book                          |      Version:  SVN                          
 Severity:  normal                        |   Resolution:  fixed                        
 Keywords:                                |  
------------------------------------------+---------------------------------
Comment (by archaic at linuxfromscratch.org):

 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.

-- 
Ticket URL: <http://wiki.linuxfromscratch.org/lfs/ticket/1745>
LFS Trac <http://wiki.linuxfromscratch.org/lfs/>
Linux From Scratch: Your Distro, Your Rules.



More information about the lfs-book mailing list