documentation for package manager
This is a package manager made for Linux From Scratch for fun, not to be intended to be used with real distros. I know most of the code is unoptimized but hey it works. This package manager is made by one person and no AI. Inspired by pacman and portage
To get started, run git clone https://github.com/ilovetrees242/Veiler.git
Once done, cd into the new cloned repo and run ./install.sh as root
The package manager will install several directories and files, and the package manager itself into the root filesystem.
/var/db/Veiler : This is the default directory which the package manager uses to store its sync database and local database for the respective packages
- sync : This directory contains the packages which the package manager uses to store the packages which are available on the package repo
- local : This directory contains the packages which are currently installed on the local system
/etc/Veiler.conf : The configuration file
/var/cache/Veiler: The default cache path for the package manger
/usr/lib/Veiler : The library directory for the package manager, which the package manager uses to store various libraries
Here are the basic operations you can do with the package manager:
- unveil : This action is used to install a new package into the system, or DEST specified by the user
- veil : This action is used to uninstall a package from the system permanently
- strengthen : This action is used to update all the packages installed on the system
- search : This action can be used to search packages or package on the sync database
- help : This action is used to display summarised information about using the package manager
- info : This action is used to display the version, name and description of a package or packages which are/is installed on the system
- version : This action is used to display the version of the package manager
- rmpkg : This action can be used to delete all the occurences of the specified package(s) in the cache directory
To install a package, you must run sudo Veiler unveil [PKGNAME] [OPTIONS]
Example packages can be acl, gettext, neofetch, which, bash, etc. Please note that the build scripts for these packages must be formatted correctly else it will perform wrong instructions
- --quiet: This option makes the package manager output way less verbose information while building and installing the packages. Normally the package manager will output very verbose messages, with this option, unimportant messages are supressed. For example, Make check outputs alot of messages as test suites are quite large, so with --quiet there will be comparitively less messages
- --ask: This option gives a confirmation prompt before performing an installation, system upgrade or uninstallation. You can use this to see what packages are being updated, how much disk space is required and what dependencies are being installed before being directly taken to the build process
- --documentation: This option allows the installation of documentation for all packages. This option exists to reduce bloat on the system, although some documentation we actually do use frequently, like for coreutils.
Note
Man pages and info files are counted as documentation.
- --test: This runs test suites after building a package ( if supported ). Test suites take really long and fail often so the package manager does not run them by default. You can if you want to though, its good to check if a package has been built correctly and properly
- --no-root: This option won't ask you to become a root user. You can use this option in pair with the --with-dest option to build and install packages whose final files will be owned by the current user. If you try to use this option and the $VEILERDEST variable contains a priveledged directory, then you will likely hit permission denied errors at the end. Also make sure that all the tarballs which will end up in $VEILERCACHEPATH will be readable and writable by the current user. Otherwise you will hit errors while extracting the build tarballs. Or use a different $VEILERCACHEPATH as an unpriveledged directory
Also note that the files in $VEILERDBPATH should also atleast be readable, but not writable ( usually )
- --skip-clean: This option does not delete every cached directory of a package, before performing installation, uninstallation or system upgrade again.
In other words, this will cause the package manager to keep the files which were downloaded in the build directory. This can be useful when you are building a package but the integrity for the build script or the source tarball could not be verified. So if the package integrity for the build script failed you can still keep the source tarball ( or you can use --skip-integrity option to not verify package integrity. Note that sometimes this can cause dirty builds
Important
The actual source directories are still cleaned. So for example, if you are building which-2.23 and then you use --skip-clean option, then the build directory will not be wiped, but the source directory will be deleted and created again. So the compilation starts again.
- --skip-integrity: Using this option, you can choose to not verify package integrity for a package. If you think the package provider is trusted and the build script is valid, then you can use this option incase integrity verification failed. Please note that this will make the package manager trust the buildscript and the source tarball 100%. You can also choose to skip integrity incase the package maintainer ( me ) failed to update checksums after updating the build script.
Note
This package manager does not really focus alot of security, but more on downloading non-corrupted files which are valid. But still this can raise a security issue
- --megabytes: If this option is enabled, the sizes will be displayed in megabytes ( MiB ) instead of kilobytes ( KiB ). Those "sizes" are the sizes related to disk space required, download size, installed size and installed size without documentation
- --skip-deps: This option will make the package manager not resolve any dependencies for the package, including optional dependencies. So incase the package manager failed to resolve the dependencies of a package properly, then you can use this option to manually make the package manager assume there are already dependencies installed on the system. However, it is advised to let the package manager resolve dependencies if it can, else you will hit errors at the configure stage
- --no-errexit: