Thinking forward LFS-7.0

DJ Lucas dj at
Sun Mar 27 01:39:59 PDT 2011

On 03/27/2011 02:32 AM, Thomas Trepl wrote:
> I think the part with additional actions (where you generate the list of
> dirs/files) should be differently tagged (<userinput remap="binpackready">  or
> so). Such actions are totally optional and everyone may want to do different
> things there (as it has not really to do with the installation of the pack
> itself) - tar it up could be such an action.
Another part I use in my own scripts now, but no intention of putting 
that into the book. I simply left it as I had it before to give some 
sort of example of how it could actually be used. A tarball would have 
been a better example.
> The "cp -R /" is now the real
> install command what previously the "make install" was, and the "install-info
> ..." is a post-install requirement. That all may needs to be sepearated
> somehow. So it seems to me that there are several different parts which even
> could be executed on quite different times:
> 1a) CMMI to the DESTDIR
> 1b) Cleanup in DESTDIR like removing usr/share/info/dir if exists
> 2) Optional actions on DESTDIR like filelists / taring etc.
> 3a) Pre-install like creating users which may own files
> 3b) Copy DESTDIR to /   (or untar to /)
> 3c) Post-install like install-info
>  IMHO separating the 3a, 3b, 3c would be quite essential for script generators

>  to be able to handle those separartly - maybe something like this:.

Good points. I'd really rather not change the number of roles, or at 
very least, minimize them if possible, however, at least a 
"post-install" role would be needed. Taking your comments above into 
account, something like this:

A "pre-install" role would cover creating users, backups, moving needed 
files to a temporary location, and other items geared toward real 
packaging. There would be no use for this in the context of LFS, 
however, so I don't really see a solution for 3a within the LFS book. It 
would fall right in first if automated externally, say if using package 
users hint, but it still is used in binary installation tasks as well. 
This will still have use in BLFS, however.

Items like unpacking additional tarballs, patching, and manual changes 
to source all fall under the "pre" role as is current. The "pre" role is 
separated from "pre-install" by the fact that binary installations would 
have no use for the "pre" role.

The "configure" role also remains as is and is self explanatory 
(includes part of 1a above).

The "make" role would now include 'make', 'make DESTDIR=blah install', 
and any cleanup items in the DESTDIR, such as removing generated files 
(/usr/share/info/dir, includes rest of 1a and 1b).

The "test" role remains the same.

If using something like jhalfs to process the book for scripting, this 
is where item 2 would come into play, but the book need not concern itself.

The "install" role now only copies the files to the final destination (3b).

A new "post-install" role, for which we do not currently have anything 
in LFS, would be for post installation tasks like install-info, perldoc 
issues (BLFS), gconf/dconf additions (BLFS), running ldconfig, and 
existing machine specific tasks like the /etc/localtime copy or adding a 
configuration file in /etc (3c).

Distribution specific tasks go here. Things like copying skel items to 
all users folders and the like simply get tacked on at the end by the 
packaging tool, again, not covered by LFS.

Does the above layout cover it in a logical and still unobtrusive manor 
(only adding a "post-install" role)?

-- DJ Lucas

This message has been scanned for viruses and
dangerous content, and is believed to be clean.

More information about the lfs-dev mailing list