On Wed, 11 Nov 2020 at 23:53, Bruce Dubbs via lfs-dev <lfs-dev@lists.linuxfromscratch.org> wrote: > > On 11/11/20 3:21 AM, Kevin Buckley via lfs-dev wrote: > > I was recently trying to generate a downlaod listing of the packages I had > > used > > when building my Pkguser based 9.1 system, inclduing the BLFS components > > that I'd merged into a single book. > > > > FWIW, so as to see what I needed to download from BLFS 10.0 > > > > I noticed that in BLFS, where the package download URIs are presented > > within the > > packages section, one ends up with entries akin to (links/lynx dump output) > > > > * Download (HTTP): https://www.domain.tld/path/to/taball.tar.xz > > * Download (FTP): ftp://ftp.domain.tld/path/to/taball.tar.xz > > > > however, in the LFS Book, where all of the package tarball URIs are listed > > in > > the one section, it's just > > > > * Download: https://www.domain.tld/path/to/taball.tar.xz > > > > or, for the odd package, > > > > * Download: ftp://ftp.domain.tld/path/to/taball.tar.xz > > > > I'm aware that there is no reason the LFS and BLS books should exhibit any > > consistency, but was wondering if having the LFS Book "adopt" the BLFS > > markup might be doable, or rather, if there was anything in way that the > > package download listing is generated that might prevent it being done? > > The design of LFS is that all the packages are expected to be built. In > BLFS, the user chooses what packages to build. > > Another issue with LFS is that there are packages only built in the > chroot environment. Downloading a package in chroot is not really > practical.
I think I might not have got the thrust of my "suggestion" across as well as I might have, so let's try again. In the LFS Book's Chapter 3.2, All Packages, is there any reason that the listings could not be displayed so that instead of, say Acl (2.2.53) - 513 KB: Home page: https://savannah.nongnu.org/projects/acl Download: http://download.savannah.gnu.org/releases/acl/acl-2.2.53.tar.gz MD5 sum: 007aabf1dbb550bcddde52a244cd1070 the "Download" line there had the same format as that of those in the BLFS book, so Acl (2.2.53) - 513 KB: Home page: https://savannah.nongnu.org/projects/acl Download (HTTP): http://download.savannah.gnu.org/releases/acl/acl-2.2.53.tar.gz MD5 sum: 007aabf1dbb550bcddde52a244cd1070 I was not suggesting (even though I have long felt there is merit in the idea) that each package section in the LFS would have a header akin to those in the BLFS Book, merely asking if some of the formatting could be made consistent between the rendered books. Just out of interest though, why does the BLFS Book often offer both an http and an ftp scheme URI for download, but the LFS Book only offers one scheme? Or, to pose that in another way, why does LFS chose to throw in the odd ftp scheme URI, even when there is an http scheme one available, for example: Libffi (3.3) - 1,275 KB: Home page: https://sourceware.org/libffi/ Download: ftp://sourceware.org/pub/libffi/libffi-3.3.tar.gz MD5 sum: 6313289e32f1d38a9df4770b014a2ca7 even though the libffi homepage says libffi-3.3 was released on November 23, 2019. You can ftp it from sourceware.org:/pub/libffi/libffi-3.3.tar.gz or download it from github here: https://github.com/libffi/libffi/releases/download/v3.3/libffi-3.3.tar.gz. so why not Libffi (3.3) - 1,275 KB: Home page: https://sourceware.org/libffi/ Download (FTP): ftp://sourceware.org/pub/libffi/libffi-3.3.tar.gz Download (HTTP): https://github.com/libffi/libffi/releases/download/v3.3/libffi-3.3.tar.gz. MD5 sum: 6313289e32f1d38a9df4770b014a2ca7 Does that help explain where I was coming from ? FWIW, I could imagine that it's tied into the automation of builds that start with the XMlL sources as the driver, in which case you are just saving yourself a little bit of extra parsing logic in the build script? Kevin -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
