What if the book wasn't a book anymore

Alexander E. Patrakov patrakov at gmail.com
Wed Feb 27 21:35:49 PST 2008


2008/2/28, Gerard Beekmans <gerard at linuxfromscratch.org>:
> What if LFS wasn't in book form anymore. What if it's an interactive
>  program instead. A 100% merge of LFS, BLFS, ALFS, <any>LFS.
>
>  It starts with running the LFS program (be it a real program or
>  collection of scripts). What is now the LFS book is on-screen instead.
>  You read the chapter portions as you work your way through an installation.

I think it is a bad idea to force interactivity for a program,
especially for those who are not first-time visitors.

>  You still have 100% control but you can decide fully manual (today's
>  style) or fully automatic style (when you've done it before and you just
>  want to get the end result).
>
>  As a package is installed (manually or automatic) present the user with
>  a wealth of information. Talk about the package that's in process of
>  being installed. Talk about whatever makes sense - anything from a
>  high-level overview to nitty gritty details where/why/how to configure
>  the package (prior to, during, or after the installation).

What you suggest is implementable without any LFS-specific program
that runs on the user's computer. Probably, this is even achievable
with a more non-linear HTML site, and definitely achievable with an
interactive PHP-based website plus a collection of spec files or other
buildscripts.

However, with the current BLFS policy on the default ./configure line
(don't include swiches that rely on optional dependencies), any kind
of standartized common automation procedure is likely to fail. The
best one can hope for is a _template_ buildscript where you should
fill in the blanks yourself after reading the output of ./configure
--help. I.e., some middle ground between a fully automated build and
the current book where the reader writes (or doesn't write) automaton
scripts for himself completely from scratch.

>  Let's take an example from today's distributions. If you want to install
>  a full desktop environment (Gnome and/or KDE for example) you end up
>  with dozens if not hundreds of packages and several hundred MB worth of
>  disk space used. The last time I asked to have KDE and Gnome installed I
>  ended up with over 600 packages downloaded, a gigabyte later, and hours
>  of waiting.
>
>  Great, I now have the environments fully installed. What exactly do all
>  those 600+ packages do and why do I need them?

I don't think that a technical solution for this problem exists,
because, at this point, it is too late to solve it. Let's rephrase an
example in some different ways:

1) A Russian user says: "I want to try out Xfce". The installation
process downloads and installs a lot of packages, including HAL. Now
the user connects his USB flash drive, only to see that Russian
filenames are all garbage (the only fix is to exlicitly mention all
possible flash drives in /etc/fstab with the correct options), and
that he has to either start Thunar or minimize all windows in order to
get to the menu that allows him to unmount this drive. He realizes
that installation of HAL was a mistake: he has to fill in /etc/fstab
anyway, and xfce4-mount-plugin provides a convenient (and
HAL-independent) way for mounting and unmounting media, that,
additionally, is not affected by the screen clutter.

2) A user from USA says: "I want to try Xfce". According to the wishes
of the Russian user, HAL is not pulled in by default. Then the US user
realizes that the installation script is crap, because the resulting
Xfce doesn't automatically start xfmedia when he inserts a DVD, and
that "missing HAL" is the real problem.

(I can also add the problem with misrecognized pirated CDs with DivX
files with the "vob" extension in the "video_ts" folder, that is
supposed to affect the Russian user and go unnoticed by the US one)

IOW: one has to see reasons for all dependencies, and the associated
problems, _before_ starting the installation.

>  Or a different example, you know you need a program installed. You
>  install it. Then you are left hanging: "Okay, now what. It's installed.
>  Somewhere. There are configuration files. Somewhere. I'm sure there is
>  documentation that answers those questions. Somewhere."
>
>  If nothing else it would be nice that after a package is installed it
>  outputs (a) page(s) of information right on your screen where the files
>  are, how it's pre-configured (if applicable), why it's pre-configured
>  the way it is. And more importantly - provide a starting point to
>  customize the product.

For second-timers, that's just SPAM on the screen.

>  If nothing else, a courtesy line "Package installed. The docs you need
>  to read now are in /usr/share/doc/package/file - they'll explain how to
>  configure it and start using the product."

Doable in HTML.

-- 
Alexander E. Patrakov



More information about the lfs-dev mailing list