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. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
