On Wed, Oct 26, 2011 at 12:53 AM, Bruce Dubbs <[email protected]> wrote:
> If someone gets a chance, I'd appreciate a review of the Berkeley DB
> section in BLFS. I'm pretty sure the install instructions are OK, for
> the most part but the testing results make me unsure -- and yes, the
> testing takes a huge amount of time -- 5 hours for me.
>
I just started the testsuite and I'll post the results when it's
finished. It'll probably take a while as the machine is somewhat old.
> Also, I'm not sure the Note concerning Java support is accurate. I
> added sharutils and it has uuencode as well as GMime (but sharutils
> doesn't have the dependencies that GMime has).
>
I wish I could provide some insight onto this, but I don't think I'll
get a chance to install Java for a week or two. I'll come back to this
if I get the opportunity.
> Also, we have Berkeley DB (and SQLite) in the section
> Servers->Databases, but neither is, strictly speaking, a server. That
> is, there is no daemon that runs for these applications. Should they be
> moved, and if so, where to? General Utilities?
>
Sorry, I intended this part of my response to be a lot shorter but
when I got thinking about it the conundrum became rather wordy.
I guess they got placed there originally due to the Database chapter.
I agree that berkeley and sqlite don't quite count as servers per se,
while mysql and postgresql definitely do. Beyond that technicality, I
can see reasoning in having the database programs side by side as
well.
Looking through the book for packages that make use of databases
directly, many of the ones that can use mysql can often use
postgresql, sqlite, and to a lesser extend even berkeley as well.
This implies that there is a good chance you can get away with only
one (or maybe two) of the database solutions in a given system,
choosing the one most appropriate for what you're going to use it for.
While database backends can be servers (which is good for high-volume
or intense workloads) they can also be simple additional libraries
(which from my experience is often used for local/private/testing
workloads).
What I'm getting at is I see two potential solutions. Either relocate
the database chapter (remove from server section entirely) or abolish
it.
I'm leaning towards the first option, perhaps extending the
introduction a bit to be a little more descriptive. The different
database systems are not always able to replace one another for a
particular application and it might be clearer to the reader if we can
point out why the book has so many database subsystems installed on
top of the gdbm from LFS itself. Plus, database backends are not
necessarily servers. I think distinction of this fact would be
healthy learning material for someone who is just trying to run php or
postfix.
If we were to split them up, then I would say the database chapter
becomes relatively useless containing only 2/4 database programs
within the book. If berk and sqlite were moved to 'General
Utilities', the same could be done with {my,postgre}sql being
potentially relocated into either 'Major Servers' or 'Other Server
Software'. However, I'm not sure that this choice has the most
potential for helping the readers understand what their options are.
Jonathan
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
