John McQuah
1f479e5397
- Updated man-pages and README - Updated copyright year - Replaced external processes with native Perl routines - Changed the interpretation of pkg-repgen's optional @ARGV to start with the target directory, like httpup-repgen - Fixed PKGINST to accommodate ports with dashes in their names
110 lines
5.2 KiB
Plaintext
110 lines
5.2 KiB
Plaintext
INTRODUCTION
|
|
----------------------------------------------------------------------------
|
|
pkg-get is a package / repository management tool for CRUX.
|
|
Syntax and features are very close to (often a carbon copy of)
|
|
the ones found in the port management tool 'prt-get'
|
|
by Johannes Winkelmann.
|
|
In fact pkg-get was developed as a prt-get/ports drop-in replacement
|
|
for systems in which it is preferable to handle binary packages instead
|
|
of compiling ports.
|
|
|
|
|
|
ARCHITECTURE
|
|
----------------------------------------------------------------------------
|
|
The client machines sync metadata files (available packages,
|
|
readme files, dependencies, etc) from a remote server (http or ftp)
|
|
OR a local path.
|
|
Once the metadata files are on the client machine, the usual
|
|
operations of installing, removing, getting info on packages
|
|
are available.
|
|
|
|
|
|
QUICK START
|
|
----------------------------------------------------------------------------
|
|
Server:
|
|
A repository can be generated using 'pkg-repgen' in a directory
|
|
containing packages. It will take a while since md5sums have to be
|
|
calculated. Alternatively, you can pass arguments to 'pkg-repgen',
|
|
specifying a repository other than $PWD, optionally followed by the
|
|
individual packages for which metadata will be created.
|
|
|
|
Client:
|
|
Adjust settings in /etc/pkg-get.conf, then use the 'pkg-get sync'
|
|
command to gather metadata from the server (if remote). You can now
|
|
use the commands as described in the manual, e.g.:
|
|
|
|
pkg-get info apache
|
|
pkg-get depinst qt6-base
|
|
pkg-get listinst
|
|
|
|
See the manual page for a detailed list of commands and options.
|
|
|
|
|
|
REQUIREMENTS
|
|
----------------------------------------------------------------------------
|
|
For the client, nothing outside the CRUX 'core' collection
|
|
For the server, prt-get
|
|
|
|
|
|
LIMITATIONS
|
|
----------------------------------------------------------------------------
|
|
The pkg-get configuration file does not offer as many settings as the one
|
|
for prt-get. In particular, you cannot change "addcommand", "rmcommand", or
|
|
"runscriptscommand"; these are hard-coded as /usr/bin/pkgadd, /usr/bin/pkgrm,
|
|
and /bin/bash, respectively.
|
|
|
|
There is also no intelligent version comparator as in prt-get; the
|
|
repository and html index are sorted lexographically according to the
|
|
current setting for $LANG. When multiple versions of a package are found
|
|
within the active collections, pkg-get will install the latest version in
|
|
the first collection that contains any such package. This behaviour is akin
|
|
to how prt-get handles dups, but with additional logic to account for
|
|
different versions of the built package within the same collection.
|
|
|
|
'pkg-get dependent' does not support the --recursive option. Other
|
|
useful prt-get commands (grpinst, fsearch, deptree, listorphans, ls,
|
|
cat, edit, cache) have no counterpart in pkg-get. Of these omissions,
|
|
only the 'grpinst' command is of possible interest for binary package
|
|
management; the unimplemented commands and options are better handled
|
|
by prt-get itself.
|
|
|
|
pkg-get only makes use of the hard dependencies listed by the port
|
|
maintainer, not any of the eager linking that might have occurred on the
|
|
build machine. As a result, 'pkg-get depinst $foo' might omit some of the
|
|
packages needed by $foo. User ppetrov^ has contributed some helper scripts
|
|
to facilitate the fixing of these broken binaries; visit the site [1] to
|
|
download them.
|
|
|
|
Further omissions related to dependencies are the absence of any mechanism
|
|
for declaring aliases (e.g., package openjdk16-bin can serve as a drop-in
|
|
replacement for the listed dependency openjdk16), and the lack of an --ignore
|
|
switch (to exclude certain packages from being installed in a 'depinst'
|
|
operation). You can work around these omissions by avoiding 'depinst'
|
|
entirely, and manually performing the desired 'install' transactions (once
|
|
you have a clear sense of what the actual runtime dependencies are).
|
|
|
|
These gaps in pkg-get's design highlight an awkward fact about trying to
|
|
erect an infrastructure for binary package management upon a foundation
|
|
designed for compiling source code (the ports tree). Inheriting the
|
|
Pkgfile's lack of separation between build-time and runtime dependencies,
|
|
pkg-get will unwittingly recurse through all the dependencies (in a 'depinst'
|
|
transaction) and install packages that you might not really need. Hence the
|
|
suggestion to consider avoiding 'depinst'. But pairing 'install' with the
|
|
helper script written by ppetrov^ [1] might not be enough to ensure zero
|
|
breakage, since revdep does not detect every runtime dependency. In the
|
|
end, you might have to manually interpolate between the footprint
|
|
recommended by 'pkg-get depends' and the (smaller) footprint
|
|
recommended by 'revlibpkg'.
|
|
|
|
In handling any new hard dependencies added by the maintainer since
|
|
the previous version of a package, pkg-get performs a sysup in the same
|
|
manner as the original prt-get (i.e., new dependencies are not injected
|
|
by default). With binary packages there's no need to carry out the
|
|
installation in any particular order, so the lack of dependency injection is
|
|
actually less of a problem for pkg-get than it was for prt-get. Combining
|
|
'pkg-get depends $foo | grep "\[ \]"' with the output of 'revlibpkg $foo'
|
|
should help identify the packages you will need to install to fix any
|
|
breakage in $foo.
|
|
|
|
[1] https://github.com/slackalaxy/depsck
|