base-lfs-massix draft 1

[Luca D. <luc...@gm...>]

Hi all

I've done a little bit of work in choosing the apps to build as
"remote-able" in the massix o.s.
I've tried to explain my point of view first.
It is not such a big work, but I had very little time.

I append to this mail my notes. They are not complete, as you can see,
for the lfs-base system.

cheers
--Luca


Note: in the examples below the directory "local" is intended
as "local to the site", not "local to the machine". See
http://www.linuxfromscratch.org/blfs/view/svn/introduction/position.html

In how many ways does it make sense to say that a package may
or may not be installed/executed remotely?

If we have some executables that could be launched from any of
our machines and some other ones that should be launched only
from the current machine.
We can place the shared ones in /usr/local/bin and the private
ones in /usr/bin. Then the PATH envvar is used to be able to
access any of them. But /usr/local/bin is a network mounted
directory, while /usr/bin is not.
The same goes for /usr/sbin (for root).

If we have some shared libraries that could be used from any
of our machines and some others that should be used only from
the current machine.
We can place the shared ones in /usr/local/lib and the private
ones in /usr/lib. Then the system default loader path tells
the system to search for shared libs in these directories.
That is, edit /etc/ld.so.conf and execute ldconfig.
But /usr/local/lib is network mounted and the other is not.

If we have some man-pages that we want to share (e.g. the man
of an application that we have shared, or a manual page that
is the same for all the versions of an application that has
been compiled in different ways in our machines) and other ones
that we don't.
We can place the shared ones in /usr/share/man and the private
ones in /usr/local/share/man. Then the MANPATH envvar is
used to be able to access any of them. But /usr/local/...
is network mounted and the other is not.
The same goes for directories /usr/share/doc and
/usr/share/info and for the envvar INFOPATH.

If a package that we share writes data about its installation
in a pkgconfig, we'll have to ensure that we use the
correct PKG_CONFIG_PATH when building new packages that
depend on this one.

If a package that we have choose to share provides include
files, or anyway we have include files that we want to be
used from any machine, and other ones that we don't.
We can put the shared ones in /usr/include and the private
ones in /usr/local/include. Then we have to use the
correct CPPFLAGS when we build new packages that depend on
this one.



For other info see:
http://www.linuxfromscratch.org/blfs/view/svn/introduction/beyond.html
  Describes how to use PATH, MANPATH and other envvar in order
  to tell to the system where to find various things.
http://xahlee.org/UnixResource_dir/_/ldpath.html
  A description by David Barr (the link from the BLFS page is
  not working anymore) on the use and misuse of LD_LIBRARY_PATH



LFS-base packages to install locally or remotely

Name                          local     remote
  1) linux-libc-headers         x
  2) man-pages                            x
  3) glibc                      x
  4) binutils                   x
  5) gcc                                  x
  6) db                                   x
  7) coreutils                            x
  8) iana-etc                   x
  9) m4                                   x
 10) bison                                x
 11) ncurses                              x
 12) procps                               x
 13) sed                                  x
 14) libtool                              x
 15) perl                                 x
 16) readline                             x
 17) zlib                                 x
 18) autoconf                             x
 19) automake                             x


Notes:
1,3 & 4) The "toolchain" is strictly related to the kernel running
in the machine, I think.
8) is composed by files that have to stay in /etc.
14,18 & 19) I think there will be no problem in putting
"bin", "lib" and "include" stuff in /usr/local. But this set of
tools (called autotools) installs many things in /usr/share:
the directories aclocal, libtool and autoconf.
How should those things be managed?
15) This is quite important, 'cause many apps come in form of perl
scripts. There is a /usr/lib/perl5 dir with a dir site_perl. We shall
understand deeper the meanings of these locations and files.
18) See 14)
19) See 14)