On 10/7/19 7:41 AM, Kevin Buckley via lfs-dev wrote:
On Sun, 6 Oct 2019 at 10:06, Bruce Dubbs via lfs-dev
<[email protected]> wrote:
I was not thinking of a section with actual build commands, just a
section to mention which packages a user might want to consider
rebuilding after LFS is complete. For instance grep can use pcre, but
the rebuild instructions are identical to those in LFS Chapter 6 after
the dependency is built. Other packages include shadow. vim, and
systemd but they are in BLFS. Just a mention about why they are in both
places may be useful to some users.
Good job you cleared that one up quickl!.
I'd got most of the way to fleshing out a subsection, index and
associated package file pages, whilst waiting for my Chapter 5
Multilib instructions to run over the weekend.
Starting point was to add a "redolfspkgs" section to BLFS's postlfs
(Part I) such that one would have:
II. Post LFS Configuration and Extra Software
3. After LFS Configuration Issues
4. Re-installation of LFS Packages
various LFS packages
5. Security
various non-LFS packages
and so on.
I think the above is way too much. Upon thinking about it, expanding
the page in section "9.4. What Now?" should be sufficient.
Generally, packages can be rebuilt with LFS instructions after the
additional dependencies are installed. A list of these similar to the
changelog format or the BLFS 'Command Explanations' format would do the
job. At each entry, it would list the dependencies you mention below
and when appropriate a link to the BLFS page with supplementary
instructions.
Also updating a package to a new version can almost always be done in
place. The only exception would be glibc. If that needs to be updated,
I feel the whole system needs to be rebuilt.
-- Bruce
No matter though, I figure I should be able to take the
"chapter" landing page I'd concocted and turn it into a
section, without too much bother.
All I did was to take the <segmentedlist> XML stanza from the
"Dependencies" appendix in the LFS 9.0 book, strip out all bar
the "Optional dependencies" <segtitle><seglistitem> blocks.
As the XML entities aren't shared across the Books, I also needed
to define the LFS Book's &external; entity in the BLFS Book's
general.ent, but it seemed to render OK, give or take a space
or two
I present the text, as I had it, in case it's moving too far
from what you were hoping for.
----8<--------8<--------8<--------8<--------8<--------8<----
Chapter 4. Re-installation of LFS Packages
Some of the packages built in the LFS Book, were installed with
reduced capability, because that capability was not required for an
LFS system, although the "optional" dependencies required to add those
extra capabilities are listed in the LFS Book.
A listing of those "optional" dependencies, taken from the current LFS
Book, is provided here:
Autoconf
Optional dependencies: Emacs
Bash
Optional dependencies: Xorg
Bison
Optional dependencies: Doxygen (test suite)
Gcc
Optional dependencies: GNAT and ISL
Grep
Optional dependencies: Pcre
Groff
Optional dependencies: GPL Ghostscript
Less
Optional dependencies: Pcre
Libcap
Optional dependencies: Linux-PAM
M4
Optional dependencies: libsigsegv
Ninja
Optional dependencies: Asciidoc, Doxygen, Emacs, and re2c
Patch
Optional dependencies: Ed
Python
Optional dependencies: Berkeley DB, OpenSSL, SQLite, and Tk
Shadow
Optional dependencies: Acl, Attr, Cracklib, and PAM
Util-linux
Optional dependencies: Libcap-ng
Vim
Optional dependencies: Xorg, GTK+2, LessTif, Python, Tcl, Ruby, and GPM
Within the BLFS Book, we have the ability to satisfy those optional
dependencies, and so re-install some LFS packages, so that they now
have those additional capabilities.
Similarly, some packages were installed with extra flags that reduced
their capability, but which could, in a post-LFS system be re-installed
with the full capability. A list of those includes:
Expect: some supplementary scripts were not installed.
Whilst there is no overriding need to re-install LFS packages, unless
an extra capability is required as a dependency for a BLFS package, or
simply desired in the post-LFS system, re-installing a package from
LFS, in full, may present a useful exercise in respect of
understanding that package.
It should also be noted that, in some cases, following a package's
instructions from the LFS book, but building it on a system where its
optional dependencies have been installed, will see the package built
against those dependencies without any extra work being required.
----8<--------8<--------8<--------8<--------8<--------8<----
One thing that I have noted, whilst creating the above:
1) Use of the term "GPL Ghostscript" in the LFS Book
In the BLFS Book, the package section title is just
"ghostscript-9.27", with a lower-case "g" and no "GPL",
and although the term "GPL Ghostscript" is used within
the section, there's no note as to why it's referred to
as "GPL Ghostscript".
Furthermore, that section starts off
Introduction to Ghostscript
Ghostscript is a ...
so again, without the GPL appelation.
Perhaps that section could be given the title
GPL Ghostscript-9.27
akin to, say,
Wireless Tools-29
which has sensible capitalisation and a space in the section title.
Whatever the thinking on that though, it'd clearly be a good thing
to have the terms used in the dependency lists the same across
the two books.
Anyroad, do let me know if that's on the right track, and I'll carry
on or, let me know if it's not, and I'll go back a step or two.
Kevin
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
