Just replying about jhalfs: On 18/06/2017 04:35, Bruce Dubbs wrote: > > At that point I wanted to use jhalfs-blfs to show me the boot order. I wanted > to build gnome, so I selected gnome-terminal and a few other items and ran > jhalfs. It seemed to work well, however all the scripts were on the debian > system because the tools needed were not yet installed on my new build. > > There does seem to be a issue transitioning from the host to lfs via jhalfs. > I really only wanted to get a build order from jhalfs and doing ls -1 > > build-order seemed to be useful. That order, with some of my notes is at > http://anduin.linuxfromscratch.org/~bdubbs/files/build-order. > > I have my sources available on an nfs exported partition and I mounted that on > the debian host as /usr/src and then 'mount --bind /usr/src /mnt/lfs/usr/src' > Now I can build in chroot! > > Starting out, there are several packages needed to really get things going. > In my case openssh, wget, nfs (libtirpc/nfs-utils/rpcbind), and sudo. Using > the order generated by jhalfs indicates to me some problems we have in the > blfs book. Most of these are issues with dependencies. For instance with > gptfdisk, popt should be recommended.
I always tick "Add blfs-tools support", so that the needed packages and their recommended dependencies are built at the end of the jhalfs-lfs run (I also use custom tools to create the start up files), so that I can usually directly boot into the new build system. > > I also note for the order generated that there are optional dependencies for a > package built after the current package. I did only ask for recommended > dependencies, but if an optional package is going to be built anyway, then it > should be before the main package, Again, popt came up as number 189 when it > could have been between numbers 6 and 7. I'm sure this would be quite > difficult to implement, but I'm just pointing out possibilities. That's a good point. Right now, optional dependencies are not looked at when asking only for recommended ones. Asking for optional dependencies at the beginning of a BLFS build generates a lot of circular dependencies, and since the software always make the choice of an order, that may generate quite a random order at the end (and also, if you want to build for example gnome or KDE with optional dependencies, you end up building almost the whole book). > > The circular dependency of freetype -> harfbuzz -> freetype was not picked up. > I think it was, but jhalfs chose an order. There is no way to detect that it is better to build freetype->harfbuzz->freetype rather than harfbuzz->freetype->harfbuzz. I know it is written in plain English in the book, but jhalfs does not understand plain English :-) So this has to be fixed manually by doing something like (using your generated order): cd scripts mv 017-z-harfbuzz 021-x-harfbuzz cp 020-z-freetype2 021-y-freetype2 A note about linux-pam, shadow, and systemd: If you ask for gnome or some other high end package, those 3 packages get (re)buit very late. So I usually build them (together with cracklib) as the first packages after building the blfs tools (sudo subversion, etc). I also build openssh (to be able to communicate from another host), and gobject-introspection before everything else. > Another issue is that package configuration needed to be done as the packages > are built to get a working system. I do not have any ideas about how to > automate that. It's a very difficult issue. Except for a few packages, the instructions in the book generates default configurations, which are enough to pursue the build. But for the other packages, there is no other way than stopping the build and configure manually. > [...] > > Back to jhalfs. > > As I was going through the list of packages, I was unsure of the versions I > had vs what was in the book. In the script names, is would be helpful if the > package version was also listed. for instance: > > 120-z-cmake vs > 120-z-cmake-3.8.2 Versions of installed packages, together with the book version are in /var/lib/jhalfs/BLFS/instpkg.xml. This file is updated when you run "make update" in the blfs_root directory. And of course, it is updated after each successful installation... I understand your use case is slightly different (not sure you used the generated scripts), but for a "normal" use, that file is enough. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
