Hi Dan,
No, I'm not currently building a base system. You're correct that we
should focus on updating the hint first. I can probably still contribute
to Part I of the hint, and to the scripts.
There are three more ideas I want to put out there before we decide what
changes to make to the hint. So, I will now take my turn to do a bit of
rambling - that way you won't feel all alone :-D
--------------- Idea #1 ---------------
Step 1. In the build script define something like,
inst_dir="/usr/installation_directory"
and then pass "DESTDIR=$inst_dir" as an argument to `make install'.
Step 2. After installation, copy all files to their correct locations by
running the following:
pushd $inst_dir > /dev/null
find -mindepth 1 -user `whoami` \
-type d -exec mkdir -pv /{} \; &&
find -mindepth 1 -user `whoami` \
-type f -exec cp -fv {} /{} \;
popd > /dev/null
This might seem like a round-about way of doing things. There is however a
potential advantage to anyone using package users:
In cases where `make install' would have failed due to permission
problems, you can now see what is going on, i.e. you can see the intended
directory structure and all associated files, and compare them with the
destination.
--------------- Idea #2 ---------------
The original hint does not provide much guidance for what group name to
assign to each package. I think it is good practice, where possible, to
make the user name equal to "<group name>-<version number>".
For example, when installing man-pages according to LFS 6.6, the command
would be,
install_package \
'The Man-pages package contains over 1,900 man pages.' \
man-pages-3.23 man-pages
Then make the default home directory /usr/<group>/<user>, eg
/usr/man-pages/man-pages-3.23.
The reason to do this is that it helps implement versioning control. If
you ever need to manage/update/downgrade man-pages, you know to go to
/usr/man-pages, and you can see there every single version you've ever had
on your system.
Furthermore, most source comes bundled as archives having names like
"man-pages-3.23.tar.bz2". Following the above naming scheme helps automate
the extraction of any sources that follow this standard.
A final advantage comes from combining idea #2 with idea #1. Instead of
installing to "/usr/installation_directory", you can install to
"/usr/<group>/installation_directory".
That way if you forget to remove the installation_directory used by a
different package, you don't get conflicts. If you want, you can keep
"/usr/<group>/installation_directory" around, as a record or as a backup.
To implement idea #2 it is only necessary (IIRC) to modify one line of
"add_package_user", where the default home directory is defined. For
people new to package users, the Hint only needs to recommend the naming
scheme I've suggested, and point out how to modify if desired.
--------------- Idea #3 ---------------
Break up the build script a bit. If you implement some of the ideas I've
suggested, here and/or on lfs-support, the build script can become quite
long and involved.
I have skel_package populated with four scripts. The central build script,
and three other sub-scripts which it sources in. These contain things like
function definitions and variable definitions. This makes the whole
package-user system easier to customise and maintain.
Sourcing in information would also be good to have set up in advance, in
case we later decide to start automating things with makefiles. In fact
I'm half tempted to start doing that today. You could have a separate
"core" script for each different stage of the build. By defining important
variables in just a single file, it would help ensure consistency.
-------------------------------------
Well, that has about laid on the table all my thoughts on package users to
date. Opinions? How much should go in the core hint, and how much should
be relegated to an appendix or to an "advanced" section of the wiki?
Cheers,
Tim
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
