Moving features from HEAD to testing

Don Smith dss-lfs at cfl.rr.com
Sat May 15 23:33:28 PDT 2004


Jeremy Utley wrote:

> On Sat, May 15, 2004 at 08:29:05PM -0500, Archaic wrote:
> 
>>On Sat, May 15, 2004 at 10:43:00AM -0700, Jeremy Utley wrote:
>>
>>>I don't see the desire to include readline as going away from the minimalist
>>
>>There is a good reason for this. And that reason is that it is easier to
>>link to the BLFS book saying you might want it versus making a build
>>page and merely saying it is optional. This is a problem for BLFS is
>>that currently it can fail safe by assuming it *isn't* installed.
>>
>>Okay, here's my question about usefulness in a nutshell. 1st, how many
>>people need history in e2fsprogs? 2nd, bash has readline built it. 3rd
>>all other packages after LFS are not LFS and as such BLFS has added it
>>for the later packages that need it. I don't have to build LFS with
>>readline to have MySQL link to readline since MySQL is in BLFS and lists
>>readline as an optional feature. Bash works fines still. I just cannot
>>see a reason why readline must be before bash or before BLFS. Please
>>open my eyes if I'm just missing the obvious in this or the above
>>paragraph.
> 
> 
> OK, picture this scenario.  LFS user installs bash, with it's internal
> readline library (which links in statically).  Then later on, installs
> the standalone readline library for BLFS applications.  Few months pass by
> and there's some major security problem found in the readline library.  User
> reinstalls a new readline with the problem fixed, BUT, bash still has the
> vulnerability linked in static.  So, this user has to reinstall 2 packages.
> 
> Second user, installed readline during chapter 6, and linked Bash to the
> external readline (shared).  Same readline vulnerability, but this user simply
> needs to reinstally the readline lib, instead of both.  
> 
> The same could be said for a new readline that simply added additional
> functionality - it's similar to the reason we use a system-installed zlib for
> XFree86 instead of the XFree86 internal zlib.
> 
> -J-

Readline is a very stable package. The chances of needing to update are 
small. Also bash is one of those necessary packages at boot/recovery 
time so you'd probably want as few external libraries as possible anyway 
just to make sure bash would always run.

It is not *required* for a functioning system (unless you consider the 
lack of command history in e2fsprogs dysfunctional). I say put a note 
saying "readline is optional - look in BLFS for instructions" in the 
bash and e2fsprogs pages. Then fully explain the matter in the readline 
entry of BLFS.

Please understand that this is only a difference of opinion and not an 
attack on you personally. You make a very valid point. There is nothing 
wrong with what you are saying. I just don't believe it will cause 
problems and you do. I believe the user should decide whether to compile 
it into the base system and I assume that you believe the editors should 
decide whether to include it. I believe in the educational value of 
making that choice. Man, this is sounding way too religious. :-)

Don




More information about the lfs-dev mailing list