Releases: pghvlaans/yalpack
yalpack-0.1.8
yalpack is a simple set of package management tools for LFS/BLFS-based systems. It consists of POSIX-compliant scripts and man pages designed to make managing upgrades and trying out new software easier:
- Install compiled software as a package
- Easily remove unwanted software
- Make upgrades simple(r)
- No space to keep package tarballs? No problem.
- Manage and log .new files
- Generate and retrieve dynamic library information to help with dependency management
- Retrieve a list of installed packages (with or without version information)
- Search for which package provided which file/directory/symlink
- Regenerate the yalpack directory in case of damage
yalpack can be used at any point in the Linux From Scratch installation process once all temporary tools have been built and the chroot stage has been reached. This has been tested successfully on Linux From Scratch 10.1 (sysvinit), as well as the development version (as of June 20th, 2021), which has a merged-usr setup.
Under no circumstances should yalpack be used on the "host" system. yalpack is untested on pre-10.1 versions of Linux From Scratch, and should not be used with glibc-2.26 or earlier.
See INSTALL or run "make all" for details about installation!
Release Notes
Unless important bugs come to light, 0.1.8 is likely to be the last yalpack release until the upcoming Linux From Scratch 11.0-rc comes out. The main feature addition is /etc/yalpack.conf, which allows the administrator to more easily choose the two backup package tree locations, the main yalpack data directory, the build destination directory and the location of the root-only scripts.
In addition, the yalpack scripts have been improved "under the hood." In many ways, these changes are more interesting. The goals here were verifying POSIX compliance and increasing speed and convenience with script optimizations. If nothing else, yalpack-0.1.8 is certainly faster and more flexible than yalpack-0.1.7!
On the POSIX front, all yalpack-0.1.8 scripts have been tested to run with /bin/sh as a symlink to bash, dash and zsh. The dash result was particularly encouraging. POSIX compliance in all scripts will continue to be a goal of this project moving forward.
Feature Changes
- Added /etc/yalpack.conf: The top-level directories used by the yalpack scripts can be specified here.
- Reworked all scripts to collect variables from yalpack.conf and perform sanity checks.
- libcheck has been reworked to be more accurate and informative; a recursive search of the library-related directories can be requested with
libcheck -d
. - Makefile:
- "make install" has been removed; "make package" should be used instead. Using the new scripts during upgrades is less prone to bugs resulting from bad interactions with the already-installed version.
- POSIX-noncompliant globs have been removed.
- Added config validation to ensure that mismatched TMP and SBINDIR values don't cause upgrade or installation failure.
- Added /usr/share/yalpack/backups: Quickly set up the primary or secondary backup location post-install. Useful if either backup location is changed in yalpack.conf.
- Renamed "pkgfind" to "yalfind." The old name didn't really make any sense, since the script actually looks for things inside packages, not packages themselves.
- Comments are now word-wrapped for readability.
Script Optimizations
Although a configuration file was introduced, along with sanity checks for every script, optimizations have made using yalpack significantly faster than before. The improvements in pkgcheck and liblist also affect the operation of pkginst, pkgup, pkgremove and restore-yalpack:
- pkgcheck: Choosing not to check for unexecutable libraries increased speeds markedly for larger packages, and dramatically for packages with a high ratio of non-executable files.
- liblist: Improved loop logic resulted in a speed increase of around 20%.
- pkginst, install.sh, restore-yalpack: Finding and reporting on files, etc. installed under symlinked paths has had a full rewrite. This reporting process in the new version is much faster than before for all packages; it takes practically no time at all for packages without symlinks to directories.
- libcheck: Unless run with --deep, improved loop logic has increased speed.
- newfiles: Cut down on calls to the main method (because newfiles is interactive, the speed is not directly measurable, but the script is now noticeably snappier).
- pkglist: Better loop logic; 50% improvement (but it was fast in any case)
Bugfixes
- pkginst, install.sh, restore-yalpack: Symlinks under non-symlinked paths are no longer reported. (This used to be possible if a symlink in a non-symlinked directory pointed to a file in a symlinked directory.)
- pkgremove: .new files installed under symlinked paths (edge case) are handled in the same manner as other .new files.
- restore-yalpack: Alerts the user to the presence of any directories under PKGTREES and exits.
- Output formatting fixes.
- newfiles: diff output is more readable.
For the Future
The plan for yalpack with respect to future LFS versions is to test the most recent releases on one LFS version only, with additional testing on the development version in case of major changes on the LFS side. Once LFS 11.0 is available, the following will occur:
- The final pre-11.0 release (probably this one) will be retained on the GitHub page; all earlier release tags that were tested against LFS 10.1 will be deleted.
- Subsequent yalpack releases will be tested against 11.0 for as long as it is the current stable LFS; once 11.1 arrives, only one of those releases will remain on GitHub.
- Repeat.
So, there will be one final yalpack release and release tag associated with each version of LFS from 10.1 onwards retained permanently. Although these releases will probably be compatible with the immediately following LFS version as well, it is too early to make a blanket guarantee to that effect. All retained yalpack releases on the GitHub page will have a notice as to which LFS release(s) they were tested against.
yalpack-0.1.7
yalpack is a simple set of package management tools for LFS/BLFS-based systems. It consists of POSIX-compliant scripts and man pages designed to make managing upgrades and trying out new software easier:
- Install compiled software as a package
- Easily remove unwanted software
- Make upgrades simple(r)
- No space to keep package tarballs? No problem.
- Manage and log .new files
- Generate and retrieve dynamic library information to help with dependency management
- Retrieve a list of installed packages (with or without version information)
- Search for which package provided which file/directory/symlink
- Regenerate the yalpack directory in case of damage
yalpack can be used at any point in the Linux From Scratch installation process once all temporary tools have been built and the chroot stage has been reached. This has been tested successfully on Linux From Scratch 10.1 (sysvinit), as well as the development version (as of June 20th, 2021), which has a merged-usr setup.
Under no circumstances should yalpack be used on the "host" system. yalpack is untested on pre-10.1 versions of Linux From Scratch, and should not be used with glibc-2.26 or earlier.
See INSTALL or run "make all" for details about installation!
Changes
This is another release more prompted by bugfixes than by new features. However, there are a few genuine additions, the most interesting of which has to do with .new file management:
- newfiles: Added .new file management capabilities to the script, including backup, overwrite, diff, etc. These have been tested to be merged-usr-safe, and preserve the .new file's ownership and mode.
- newfiles and restore-yalpack are no longer given .new suffixes.
- Makefile: "make package" can be used for upgrades as well as installations. This is now the recommended installation method for both. For upgrades, using "make package" means that the new versions of the scripts will run to install themselves as a package, mitigating potential upgrade bugs.
- Added an 'executive summary' man page at yalpack(1).
Bugfixes include:
- pkgmake: Handling of non-text files in etc has been fixed (relevant for glibc).
- Adding "make package"-based yalpack upgrades fixes the overlapping-secondary-backup problem, as well as issues moving from /sbin to /usr/sbin.
- pkgup: Removed a spurious message about missing /sbin/init with existence checks.
- pkgup, pkginst, pkgremove: Specify SBINDIR as a variable.
- install.sh: No longer copies "YALPACK-OUTGOING" (if any) into new backup directories.
- Output formatting corrections.
On a personal note, I'd like to apologize for the flurry of releases over the last few days. Unless important 0.1.7 bugs come to light, there will probably only be one more release before LFS 11.0 rc. The focus of yalpack-0.1.8 will be the addition of /etc/yalpack.conf, which will simplify customization.
yalpack-0.1.6
yalpack is a simple set of package management tools for LFS/BLFS-based systems. It consists of POSIX-compliant scripts and man pages designed to make managing upgrades and trying out new software easier:
- Install compiled software as a package
- Easily remove unwanted software
- Make upgrades simple(r)
- No space to keep package tarballs? No problem.
- Manage and log .new files
- Generate and retrieve dynamic library information to help with dependency management
- Retrieve a list of installed packages (with or without version information)
- Search for which package provided which file/directory/symlink
- Regenerate the yalpack directory in case of damage
yalpack can be used at any point in the Linux From Scratch installation process once all temporary tools have been built and the chroot stage has been reached. This has been tested successfully on Linux From Scratch 10.1 (sysvinit), as well as the development version (as of June 20th, 2021), which has a merged-usr setup.
Under no circumstances should yalpack be used on the "host" system. yalpack is untested on pre-10.1 versions of Linux From Scratch, and should not be used with glibc-2.26 or earlier.
See INSTALL or run "make all" for details about installation!
Changes
This is a minor release:
- Changed bold text output to underlined (renders as cyan - or a user-defined Color 6 - on tty)
- Bugfix: The new install.sh script was put in the wrong location on the GitHub repo
For a complete list of other changes since yalpack-0.1.4, which are much more extensive, see the release notes for yalpack-0.1.5.
yalpack-0.1.5
yalpack is a simple set of package management tools for LFS/BLFS-based systems. It consists of POSIX-compliant scripts and man pages designed to make managing upgrades and trying out new software easier:
- Install compiled software as a package
- Easily remove unwanted software
- Make upgrades simple(r)
- No space to keep package tarballs? No problem.
- Manage and log .new files
- Generate and retrieve dynamic library information to help with dependency management
- Retrieve a list of installed packages (with or without version information)
- Search for which package provided which file/directory/symlink
- Regenerate the yalpack directory in case of damage
yalpack can be used at any point in the Linux From Scratch installation process once all temporary tools have been built and the chroot stage has been reached. This has been tested successfully on Linux From Scratch 10.1 (sysvinit), as well as the development version (as of June 20th, 2021), which has a merged-usr setup.
Under no circumstances should yalpack be used on the "host" system. yalpack is untested on pre-10.1 versions of Linux From Scratch, and should not be used with glibc-2.26 or earlier.
See INSTALL or run "make all" for details about installation!
This is the most comprehensive upgrade to yalpack since the repo went public; it is better-looking and more convenient than ever.
Changes
With merged-usr set to be introduced in the upcoming LFS/BLFS 11.0, the main focus of this release is improving the handling of symlinks (and paths containing symlinks) to ensure that yalpack can be used safely from September 2021:
- The yalpack directory tree now includes SYMTREES; the files within are generated at package installation time, and are intended to show the non-symlinked locations of items installed under a path containing symlinks.
- yalpack now includes its own install.sh script, which will make and populate the SYMTREES directory if necessary.
- In preparation for the new LFS directory structure, the default SBINDIR for yalpack is now /usr/sbin. Scripts and documentation have been updated accordingly.
- pkginst:
- The installation unpacking now dereferences for hard and symbolic links.
- A SYMTREE file is generated if necessary (if it is, it means that either the package has a symlink to a destination owned by another package, or something was installed under a path with a symlink).
- pkgup: Added mechanisms for handling the outgoing-package SYMTREE, if any.
- pkgremove:
- Checks for paths with symlinks during file deletion.
- Merged-usr related symlinks are protected from removal in all cases (hardcoded)
- Symlinks pointing to locations required by another package can be replaced,but not deleted.
- Handling the outgoing-package SYMTREE, if any.
- pkgfind now searches in SYMTREE files to provide more comprehensive results.
- "liblist -n" and libcheck now skip top-level directories that are symlinks (avoiding double work for both and duplicate results for libcheck).
A second area of emphasis is the addition of backup and regeneration capabilities:
- Added restore-yalpack: Use a parallel copy of the package trees directory to restore the /var/yalpack directory in case of var accidents. (placed in /usr/share/yalpack)
- install.sh: In addition to populating SYMTREES, install.sh also sets up parallel package tree directories for backup purposes.
- pkginst, pkgup and pkgremove have been modified to update the parallel package tree directories, if present.
Other quality-of-life changes include:
- .new files are now documented separately for each package. install.sh will generate the new directory and .new file lists for all installed yalpack packages.
- NEWFILE-LOG was horrible. It is now deprecated.
- Added newfiles: Update the NEWFILES directory to reflect currently-existing files on the system (placed in /usr/share/yalpack); display the lists if desired.
- pkgremove and pkgcheck: Loop logic has been altered to increase speed.
- pkgmake: Only non-binary files are designated .new by default.
- Output formatting has been improved for all scripts (better spacing, less verbose).
- Variable names have been edited to be more consistent across scripts.
- Workarounds for installing bzip2, SysVInit and sysklogd are now documented; build scripts for the latter two can be found in the doc directory.
- Added a list of man pages to the doc directory.
Bugfixes:
- Absolute symlink repair with the tar installation method has been fixed.
- "telinit U" failures are ignored by pkgup (needed if glibc or SysVInit upgrades are done under chroot).
- pkgcheck no longer misses .new executable files that have been renamed or removed by pkginst. Handling of symlinks reworked.
- pkgremove no longer fails to delete directories containing only empty directories belonging to the deleted package (and so on).
yalpack-0.1.4
yalpack is a simple set of package management tools for LFS/BLFS-based systems. It consists of POSIX-compliant scripts and man pages designed to make managing upgrades and trying out new software easier:
- Install compiled software as a package
- Easily remove unwanted software
- Make upgrades simple(r)
- No space to keep package tarballs? No problem.
- Manage and log .new files
- Generate and retrieve dynamic library information to help with dependency management
- Retrieve a list of installed packages (with or without version information)
- Search for which package provided which file/directory/symlink
yalpack can be used at any point once all temporary tools have been built. This has been tested successfully on LFS 10.1 (sysvinit). Under no circumstances should yalpack be used on the "host" system.
See INSTALL or run "make all" for details about installation!
Changes
Applying this update is strongly encouraged. pkginst and pkgup have been improved with an eye to making yalpack upgrades of glibc and SysVinit possible while retaining convenient .new file- and symlink-related features.
- pkginst: After handling .new files and fixing symlinks, the package contents are re-archived and extracted over root to install.
- pkgup: init is reloaded after glibc and SysVinit upgrades (prevents umount failures upon the next halt or reboot).
- Added pkgfind, a script for finding out which package provides a given file, directory or symlink.
- Updated man pages.
yalpack-0.1.3
yalpack is a simple set of package management tools for LFS/BLFS-based systems. It consists of POSIX-compliant scripts and man pages designed to make managing upgrades and trying out new software easier:
- Install compiled software as a package
- Easily remove unwanted software
- Make upgrades simple(r)
- No space to keep package tarballs? No problem.
- Manage and log .new files
- Generate and retrieve dynamic library information to help with dependency management
- Retrieve a list of installed packages (with or without version information)
yalpack can be used at any point once all temporary tools have been built. This has been tested successfully on LFS 10.1 (sysvinit). Under no circumstances should yalpack be used on the "host" system.
See INSTALL or run "make all" for details about installation!
Changes
The main changes have to do with the handling of file ownership at package installation time:
- Any .new file is now installed with the same ownership and permissions as the already-existing file on the system.
- Ownership is always preserved from the package tarball. This is necessary for packages such as CUPS.
- pkginst and pkgup can now be called with the option --root-own (-r), which changes the ownership of all files and new directories in the package tarball to root:root before installation (the ownership of existing directories will not be changed). This is potentially useful if the package contents are owned by a non-privileged user.
Other changes include:
- Bugfix: The upgrade workflow was altered when pkgup was modified to handle upgrade operations without the outgoing package tarball (pre-release). This introduced package upgrade bugs related to libraries and the correct workflow has been restored.
- A customization guide is now included for build destination and data directory location.
- Reworked variable names to make customizing the location of the yalpack data directory more convenient.
- The build destination top-level directory (/tmp by default) can now be passed when calling "make package" to install yalpack.
- Man pages have been updated to reflect new information and functionality.
yalpack-0.1.2
yalpack is a simple set of package management tools for LFS/BLFS-based systems. It consists of POSIX-compliant scripts and man pages designed to make managing upgrades and trying out new software easier:
- Install compiled software as a package
- Easily remove unwanted software
- Make upgrades simple(r)
- No space to keep package tarballs? No problem.
- Manage and log .new files
- Generate and retrieve dynamic library information to help with dependency management
- Retrieve a list of installed packages (with or without version information)
yalpack can be used at any point once all temporary tools have been built. This has been tested successfully on LFS 10.1 (sysvinit). Under no circumstances should yalpack be used on the "host" system.
See INSTALL or run "make all" for details about installation!
Changes from 0.1.1
- Some of the man pages contained outdated information reflecting the pre-release state of yalpack; this has been fixed. I apologize for any inconvenience.
- Other changes to the man pages for style and clarity
- Wording changes in the README files
yalpack-0.1.1
Initial release.
yalpack is a simple set of package management tools for LFS/BLFS-based systems. It consists of POSIX-compliant scripts and man pages designed to make managing upgrades and trying out new software easier:
- Install compiled software as a package
- Easily remove unwanted software
- Make upgrades simple(r)
- No space to keep package tarballs? No problem.
- Manage and log .new files
- Generate and retrieve dynamic library information to help with dependency management
- Retrieve a list of installed packages (with or without version information)
yalpack can be used at any point once all temporary tools have been built. This has been tested successfully on LFS 10.1 (sysvinit). Under no circumstances should yalpack be used on the "host" system.
See INSTALL or run "make all" for details about installation!