3.7 Package: delete the reference to rust-bin in the examples of prt-get aliases

This commit is contained in:
John McQuah 2022-08-12 07:17:03 -04:00
parent d2ad588835
commit d7881afde5
1 changed files with 16 additions and 24 deletions

View File

@ -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