John.Arrowwood at merant.com
Fri Sep 1 10:13:38 PDT 2000
Just a bunch of thoughts thrown together.
First, we should list "requirements" for the project. You always paint
yourself in a corner when you start a project without first defining exactly
what you are trying to accomplish.
* I will not be storing the packages on the LFS partition. The installer
must have a way of getting to them from the chroot'd environment. (I have a
proposed solution, btw)
* I want to be able to restart the setup after a failure, and have it skip
the packages that were successful.
* If I download a new source archive, or make changes to the compile options
to the package, then re-run the setup script, it should detect that and
re-install the package.
* I should be able to easily find and modify the options used to compile a
particular package, without having to go wading through a huge file of stuff
for all the other packages, if at all possible.
* Check to make sure the barest essentials are available on the host system,
and complain if they do not exist
* Bootstrap yourself by installing packages needed to install other packages
in such a way that they will be usable both in the host system and in the
chroot'd environment, because you can't rely on the host having everything
* I want to be able to pick-and-choose what packages (at least what OPTIONAL
packages) I install. If I select an optional package that requires some
other optional package, the installer should auto-include the required
packages. Don't ask, just do it...
* And I'd like to see more packages added to the mix, like X, KDE (or
gnome), XMMS, and stuff, all optional.
How to solve them...
Start by scanning the path for a few key executables. If they don't exist,
exit with an error. Don't list everything, just the stuff you HAVE to have
in order to bootstrap yourself up. Then, compile the static packages and
install them into the LFS partition in such a way that they can also be used
by the host by adjusting the path and making a symlink, etc.
Currently, the plan is to chroot into the LFS partition and do the second
stage install. This requires that the package sources be available on the
LFS partition, which means downloading them, and then copying them. This
works, but increases disk space requirements, and isn't necessary. You can
chroot just to do a single command, rather than a whole bunch of them. So,
you run chroot to run configure, and again to run make, and again to run
make_install. And if you want your code to be the same for all stages, just
manipulate the chroot path... if you chroot to "/", it works! So every
configure, make, and make_install command can be executed in a chroot'd
environment, just change the path that is used. Just an idea...
During install, the system should keep a record of what it installs.
Perhaps a checksum of the package profile, a filename and timestamp or
checksum of the source tarball, and a success/fail status. Then, if the
install crashes, and the user makes a few changes to fix it, then starts it
again. The next time, before it installs a package, it checks the database,
finds that the package has already been sucessfully installed, then checks
to make sure that neither the tarball nor the package profile have changed.
If not, it skips the package. If it has, it re-installs it.
Packages will also need requirements info in their profile. And SOME form
of selection process should be provided. It would be good enough to just
have a file in the same directory that lists the optional packages that are
available, and you can comment out or delete the entries for the ones you
don't want installed. Start simple, slap a nice gui on it later...
Another thing to think about: There are lots of "extra" stuff that some of
the packages require, which means that the profile should be able to handle
it. For example, gcc and glibc require being compiled in a separate
directory. And glibc requires additional packages to be extracted into the
source directory. And the list goes on and on. The profile data should be
extensive enough that it can handle all of these special cases, but not so
generic that you are specifying shell script commands in the XML, as at that
point you might as well just use shell scripts, and all the benefits of XML
are lost. Before we finalize the XML structure, we should go through the
book and make sure that all of the steps that are required for every package
can be captured in an abstract way.
Okay, enough thoughts for now...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the alfs-discuss