Moving features from HEAD to testing
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
> 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.
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. :-)
More information about the lfs-dev