documentation for package manager

About this package manager

This is a package manager made for Linux From Scratch for solving the issue of upgrading of packages and dependency hell, 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 purely written in bash script and is made by one person and no AI. Inspired by pacman and portage

Contributing

If you care to contribute, it would help alot if you contribute in fixing small bugs and expanding the package repository. Theres like 200+ packages built in LFS which would be a pain for me

Using the package manager in your system.

You can use this package manager on your system, but you have to take precaution because this package manager has not been tested enough to find bugs. Incase you find any bugs raise an issue on GitHub or contact me through discord (rblox0213) or mail me.

Installing the package manager

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

Getting started

Basic operations

Here are the 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
• pkgs : This action is used to list the number of packages installed. Useful for other programs like fetch programs on the system
• list : This action is used to list the names of all of the packages installed. Useful for other programs like fetch programs on the system
• dumpvars : This action can be used to display all of the variables which affect the main operation of the package manager. Example: Useflags, Repository, Prefix, etc. Note that values of these variables are their final values given after parsing the configuration file. Useful for quickly checking variables
• stat : This action is used to display information of all installed packages. It lists out things like installed files size, number of installed files and number of installed packages.
• stat : This action is used to display information of all installed packages. It lists out things like installed files size, number of installed files and number of installed packages.

Using useflags while installing packages

USEFLAGS in this package manager are implemented the same way as they were in gentoo. There are global useflags which set useflags visible to all packages, and local useflags that only set useflags for a specific package.

How to set global useflags:

/etc/Veiler/veiler.conf: You can use this file and set the USEFLAGS variable to the desired useflags you want for the packages to be installed. These useflags must be space seperated in order to work properly. Example: USEFLAGS="+MULTILIB -NLS -RPATH"

How to set local useflags:

/etc/Veiler/package.use: You can use this file and enter the name of the package in a new line, followed by "->" and then the useflags seperated by space. Example: which -> -RPATH +GNULD -NLS

Installing a package

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

Using the options

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


• --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, installed size without documentation and upgrade sizes


• --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: Using this option, you can choose to skip exiting upon errors encountered during buildtime and installtime. Errors like downloading errors or invalid variable value errors will still cause the package manager to exit. Also you can skip exiting if you have insufficient disk space ( but its not advised to do so )


• --skip-description: Using this option along with the search operation, you can tell the package manager to only search for packages in the sync database by names, and not by matching the description and the name itself.

Example case

Lets say you want to search the package "which" in the package managers's database, and by name only not description. If you omit --skip-description then the package manager will also search the arguments you provided to it in the packages's descriptions.



• --skip-installed: This option will make the package manager skip installing the packages which are already installed on the system. Suppose you want to install the following packages: which bash neofetch fastfetch. And you already have neofetch installed and you want to skip building and installing the packages which are already installed on the system. Then in that case you can use --skip-installed option to skip building packages which are already installed, which in this case will make the package manager install the following: which bash fastfetch


• --with-dest: This option requires an additional argument to be used. Using this option, you can choose to install packages in a custom directory instead of the default directory /. Note that argument provided to this option must be an absolute path, otherwise it can cause issues at install time.


• --config: This option also requires an additional argument to be used. Using this option, you can choose to use a custom configuration file instead of the default configuration file /etc/Veiler/veiler.conf. Note that argument provided to this option must be an absolute path.


• --build-only: This option is used to skip the installation of a package, and only build a package. Useful for custom installations

Using the configuration file

Introduction

You will find the configuration file for Veiler at /etc/Veiler/veiler.conf after installing the package manager. You can use the configuration file to set default options everytime you perform an action with the package manager instead of having to use commandline options again and again

Variables

A table of variables which are valid

Path variables

Introduction

This section will contain information about the path variables, which affect the usage of certain directories by the package manager. These variables are simply just path to directories with a special purpose

PKG Repo path

Introduction

PKG Repo path basically contains the URL to the package hosting repository. The package manager uses wget to download files from the internet through the https. The hosting package repository must contain to things:

• [PKGREPO]/Patches: Will contain all the patches, for fixing upstream code bugs

• [PKGREPO]/Packages: Will contain the actual build tarballs, which contain the integrity file and buildscript

How to use

To use PKGREPO, you need to first of all host the repository, and then the package manager will download packages from the repository through http. Patches should be applied in the buildscript itself. The [PKGREPO]/Packages is what you need to set as PKGREPO. Once you do that, it should contains tarballs like this:

After you have that, the tarball should contain the file called MOONBUILD along with another file called integrity.sha256

DB Path

Introduction

The DB path is the database of the package manager, non-sql which lives on the filesystem. Instead of SQL or JSON to query data, the package manager queries a package entry in $VEILERDBPATH/sync. If the package is not found, the package manager will exit with an error. Otherwise, it will proceed with the installation. Each package entry mainly contains 5 files:

• files Contains the installed files on the system. This file is dynamically created after the installation of a package, only under $VEILERDBPATH
• docfiles Contains all the documentation files for the package. This file is not dynamically created and its contents are static. After an installation, the package manager reads this file and deletes all the files listed in the staging area.
• info The most important file. This file contains the actual data related to the package. It is an executable file which contains shell variables, and the package manager reads the data by sourcing this file. Heres what the file contains:

• Title ( NOT A VARIABLE ) This is the first line of the file which is a comment. It contains the name of the package, and in brackets its full form. Example: Perl ( Practical extraction and report language )

• MOONPKGNAME This variable contains the name of the package. This name is used for extracting and configuring the package throughout the installation. Example: tcl

• MOONPKGVERSION This variable contains the name of the package. This name is used for extracting and configuring the package throughout the installation. Example: tcl

• MOONPKG This variable contains the full name of the package. It is defined by deliminiting $MOONPKGNAME and $MOONPKGVERSION by a '-'. Example: which-2.23

• EXTENSION This variable contains the extension of the source tarball. It can be .tar.xz, .tar.zstd, .tar.gz, .bz2, .tar.bz2, or zip. The package manager will use this as the extension of the source tarball after downloading it. Example: .tar.xz

• SRC This variable contains the package source. The upstream URL for the package is used here. You can use variables in this to make it more efficient. Example: https://mirrors.hopbox.net/gnu/glibc/glibc-2.43.tar.xz

• DESC This variable contains a brief, precise description of the package. It denotes the purpose of the package, no explanation. Example ( for gcc ): The gcc package contains the gnu compiler collection for compilation of various programming languages

• INSTALLEDSIZE The default space in bytes which is taken up by what the package installs. Example: Zlib's libraries may take up around 500KiB, or some other X package's libraries, programs and documentation may take up 25MiB

• WODOCINSTALLEDSIZE The installed size without the package's documentation.

• DOWNLOADSIZE The download size of the package ( including patches and additional downloads ).

• REQDSKSPC The required disk space without for the package ( no test suites ). This does NOT include the installed size. So if you want to calculate the REQDSKSPC size, then you need to remove the installed files and only count the buildscript, checksums files and the package sources

• dependencies This file lists the dependencies REQUIRED in order to build the package. It shall list both build-time dependencies and required-dependencies. Although, required dependencies is a must. Writing invalid package names will lead to package not found errors in the package manager.
• optdependencies Optdependencies exists to list out the optional dependencies for the package manager. However, just listing the package names is not enough, you have to put the name of the USEFLAG in the first column which would be used to identify the package listed in second column as an optional dependency. The package manager then checks this file if it exists and its size is greater than 0, and then it compares the USEFLAG listed in the first column with either USEFLAGS specified in package.use or /etc/Veiler/veiler.conf.

  Example case

  Here's an example from htop: +SENSORS lm-sensors

• testdependencies Dependencies which are required for running test suites. If you have --tests option disabled then this file is not read.
• additionaldownloads Contains additional download for the package. Could be documentation tarball, extra modules, etc. For example, Tcl ships its seperately from the source, or even python.
  
  

  How to use

  
  

  Using DB Path is very simple. You can use any accessible directory as the DB and then you can create package entries in sync, and then you just have to create the above listed files in each of the entries. Entries are directories by the way. Local directory will be just a duplicate of sync which will be used to keep track of installed packages. If the package you provide to the package manager to install does not exist under the sync directory then an error will be thrown. Empty dependencies file means no dependencies

  Cache Path

  Introduction

  The cache path is simply an absolute path to the directory which should contain all the downloaded build tarballs. The tarballs are stored in this directory for later use, and you can delete them with the package manager's operations: rmpkg and clearcache. Note that these contain the package source ( if integrity verification was successful ) which causes them to be large in size

  /var/cache/Veiler vs x directory

  /var/cache/Veiler is the default cache directory which is owned by the build user and is not writable by other users. Meanwhile, if you are using x directory for cache, it should usually be paired with --no-root because it may not be writable by the build user. Use this if you want to build packages as your user.

  How to use

  To use cache path, simply ensure it is writable and accessible by your user. And then all the downloads will be stored here. You can use something like /tmp, or /home/user/.cache/veiler.

  Prefix

  Introduction

  Prefix is the directory under which packages will be installed. By default it is set to /usr because it is the directory which is tracked by the system's package manager. You can change it to something like /usr/local for site installations.

  How to use

  For using this, you need the prefix to be an absolute path to a directory which exists. So under the prefix you use, the packages will install their files under it.

  Dest

  Introduction

  Dest is a special absolute path to a directory where the package will be installed. This is very useful for custon installations or test installations. You can use this when you don't want to install something directly to your main root filesystem

  How to use

  Usage is very simple, just use $VEILERDEST or --with-dest. --with-dest requires an argument to the absolute path of the destination directory.

Creating your own packages

Introduction

Alright, last but not least creating your own packages. This section will explain things like adding the package to the database entry, creating a buildscript for it and adding it to the package repo

Things required for a package

• A valid database entry with a proper info file ( MOONPKGNAME and MOONPKGVERSION must match the respective name and version of the package in the repo )
• A proper MOONBUILD build script
• Optionally an sha256 file containing the checksums of the buildscript, source tarball and other downloads ( recommanded )

Creating a buildscript for a package