On 01/11/2015 12:24, EyesIs Mine wrote: > > I guess as one of the very few active users of jhalfs, I'm gonna comment here. >
Thanks for that. I almost never receive feedback about this tool, and I am glad to see that someone is using it. >> - Pages with no version are not considered by the tool, but may be needed as >> dependencies (for example CA certificates for p11-kit and gnutls), or to set >> up the environment (for example "Configuring the JAVA environment" and >> "Setting the PATH for TeX Live"). I think the <sect1info><date> tag could be >> used as version for those pages. > > Maybe they could be downloaded when those pages were imported and rolled into > one, > to save time or something. This means no version check would be required, because > (hopefully) the pages would be up-to-date with the packages they concern. I am not sure I understand. Do you mean that, for example, the "Configuring the JAVA environment" page could be somehow included into the Java and/or OpenJDK pages by the tool (BLFS devs prefer to have those pages separate)? That may be a solution. >> - There is presently no way to know which bootscript to reinstall when the >> bootscript tarball is modified. Having a file of installed bootscripts could >> help (or maybe use the listing of "/etc/init.d"). > > systemd says hi. Also, this would mean overwriting modified bootscripts, > which would be bad. Maybe a solution could be worked with sha256sums or > something along those lines. > Sorry about systemd... Actually, I have to check, but it seems the current tool is unable to install systemd units, is it? Maybe the first task would be to make the tool compatible with systemd. Thanks for the heads up. Managing new versions of the scripts/units is tougher, and I might come to that later. >> - There is no way to build perl modules external (not in the book) >> dependencies. It would be interesting to find a way to do that. The main >> problem is that the book lacks version information for those dependencies, >> and >> I am not sure it is easy to find the latest one. > > Maybe this is not an issue with jhalfs-blfs, but one that needs to be > forwarded > to blfs-dev? > I usually try to adapt the tool to the book rather than the converse, because I am not sure the devs would accept to write instructions "jhalfs ready": It's already hard enough to produce a working set of instructions without having to account for this tool. I guess a small Perl script would be able to find the last version and to retrieve the package. My main concern is that I know very little of Perl :-/ >> - There should be a way to store build logs, build scripts and possibly the >> used dependency tree. Presently, they get destroyed when running make in the >> blfs_root directory. OTOH, indexing those logs is not easy, since very often, >> a list of packages is given to be built, and they each pull their >> dependencies, so that the logs (same for the scripts and deps) are all >> grouped >> in one unique directory, the naming of which can never be enough to retrieve >> one particular package information. > > Maybe the buildscripts should put their logs in separate directories inside > the whatever directory it is in now, meaning that you could clearly see what > pulled down what. Good point: Actually, for each list of packages built, there are files pertaining to only one package (script, log, and possibly some info available when the figure computation is added), and files pertaining to the whole list (Makefile, dependency tree, book-html). So we could keep the package info in a separate directory for each package (say with some info in the file name to allow retrieving the build date, like package-version-buildinfo), and the global info in a dir with a name containing the same information, say global-date-buildinfo. Thanks for your comments Pierre -- http://lists.linuxfromscratch.org/listinfo/alfs-discuss FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
