diff --git a/crux-wiki/Handbook3-7-Package b/crux-wiki/Handbook3-7-Package
index eaaaa5e..f867dab 100644
--- a/crux-wiki/Handbook3-7-Package
+++ b/crux-wiki/Handbook3-7-Package
@@ -143,7 +143,7 @@ remove that file manually. Another option is to use '''rejmerge'''. For each
 rejected file found in %fn%/var/lib/pkg/rejected/%%, rejmerge will display the
 difference between the installed version and the rejected version. The user can
 then choose to keep the installed version, upgrade to the rejected version or
-perform a merge of the two. Example (using the above fn%/etc/pkgadd.conf%%):
+perform a merge of the two. Example (using the above %fn%/etc/pkgadd.conf%%):
 
  $ pkgadd -u bash#5.0.18-1.pkg.tar.gz
  pkgadd: rejecting etc/profile, keeping existing version
@@ -418,15 +418,6 @@ can be accomplished with the following line in %fn%prt-get.aliases%%:
 mozjs91: duktape
 @]
 
-Another case where aliases might be useful would be that of replacing a
-slow-compiling source port with a precompiled binary port in order to save time.
-For example the following would indicate that '%fn%rust-bin%%' is considered
-sufficient to satisfy a dependency on '%fn%rust%%' in a port:
-
-[@
-rust-bin: rust
-@]
-
 ->%lfloat%http://crux.nu/doc/images/note.png
 '''Note'''[[]]
 ->''prt-get's alias function does NOT automatically replace ports during an
@@ -527,7 +518,7 @@ build() {
 the program is built in some other way, e.g. does not use '''autoconf'''.''
 
 When the build() function has been executed, the %fn%$PKG%% directory will be
-made into a package named fn%''<name>#<version>-<release>''.pkg.tar.gz%%. Before
+made into a package named %fn%''<name>#<version>-<release>''.pkg.tar.gz%%. Before
 the package creation is completed, '''pkgmk''' will check the contents of the
 package against the %fn%.footprint%% file. If this file does not exist, it will
 be created and the test will be skipped. The %fn%.footprint%% file will contain
@@ -626,19 +617,20 @@ currently recognize git urls in the %fn%source%% array, efforts are underway
 to add this feature, thereby removing the temptation to write a build function
 that reaches out to the internet for the latest git source tree.
 
--> The motivation for a policy of separating 'download' from 'build' is that a
-user with intermittent internet access should be able to run @@pkgmk -do@@ in
-the directory of every outdated package, and then go offline to finish the sysup
-operation. Language-specific toolchains, like those embraced by rust and python
-(cargo and pip, respectively), are making this policy more difficult to enforce.
-You are free to forego CRUX pkgutils and let the ecosystems of the ''N''
-different languages manage their respective software in separate subdirectories
-(like python's %fn%~/.local/share/virtualenv%% or rust's %fn%~/.cargo%%), at the
-expense of having to learn ''N+1'' administration suites rather than just the
-1 suite of CRUX pkgutils. Every language-specific project that appears in the
-official repositories represents a hard-won effort by the CRUX team
-to sustain the historic method of software deployment, in the face of software
-development trends all heading away from this model.
+-> Apart from ensuring a consistent mechanism to verify the integrity of sources
+(@@signify@@), the policy of separating 'download' from 'build' allows a
+user with intermittent internet access to run @@pkgmk -do@@ in the directory of
+every outdated package, and then go offline to finish the sysup operation.
+Language-specific toolchains, like those embraced by rust and python (cargo and
+pip, respectively), are making this policy more difficult to enforce. You are
+free to forego CRUX pkgutils and let the ecosystems of the ''N'' different
+languages manage their respective software in separate subdirectories (like
+python's %fn%~/.local/share/virtualenv%% or rust's %fn%~/.cargo%%), at the
+expense of having to learn ''N+1'' administration suites rather than just the 1
+suite of CRUX pkgutils. Every language-specific project that appears in the
+official repositories represents a hard-won effort by the CRUX team to sustain
+the historic method of software deployment, in the face of software development
+trends all heading away from this model.
 
 !!! Directories