Hello,

firstly, thanks for an excellent resource in BLFS - if it wasn't there I almost
certainly wouldn't have been able to gain the insight to offer these thoughts.

I'd like to offer up a small concern over what BLFS promotes as the "Core"
of Gnome2 and suggest that it could perhaps be cut down a little.

Background:

Because some of the packages curently in BLFS, GnuCash < 2.0 will be my case in
point here, are still required to be compiled against the older Gnome
libraries, BLFS
contains a section entitled ""Gnome-1.4 libraries" in whch it states

"This section contains GNOME 1.4 libraries, needed by some
applications that have
 not yet  been ported to GNOME 2.x. None of these libraries are
needed for a GNOME
 desktop installation."

Issue:

What I'd like to see pointed out (or refuted ?!) is that not all of
what BLFS terms as
" GNOME Core Packages" for Gnome 2.X is actually needed to compile what can
be thought of  as Gnome2 software.

" GNOME Core Packages" in BLFS would actually seem to be a Gnome desktop,
complete file manager and terminal emulator.

Justification:
 (hopefully)

I was recently able to get a working, albiet not a fully-"pzazzed" but
a still more than
functional as a ledger, version, of GnuCash2 working on an LFS/BLFS system,
using only the following 17 Gnome packages (and yes, before folk who are on
both LFS/BLFS  and Gnome lists dive in, I have bonuced this off a Gnome devel
list and it does seem  that what I ended up with was a current minimum)

# Orbit2
# libbonobo
# gconf
# gnome-mime-data
# gnome-vfs
# libgnome
# libglade
# libart-lgpl
# libgnomecanvas
# libbonoboui
# gnome-keyring
# libgnomeui
# libgnomeprint
# gnome-icon-theme
# libgnomeprintui
# gail
# gtkhtml

Suggestion:
(and it is only a suggestion)

Might BLFS consider splitting what is really the core Gnome (assuming it can be
defined to be less than what is specified that at present), ie that
required for
the development of other Gnome or written-for-Gnome packages, out from what
seems to be a section on building a Gnome desktop.

Interested as ever, to hear the thoughts of folk with a better grasp
of the full story
behind the way BLFS is laid out and by which itspackages are grouped together.

Thanks again for making it possbile for me to air these views,
Kevin
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to