Solus linux package manager

Help Center

Get answers to common questions

Packaging Using a Local Repository

This guide walks you through the steps necessary to tell solbuild how to utilise locally built .eopkg’s that are not yet in the Solus repository.

We assume you have worked through the packaging material for creating a package with solbuild.

Install the local profile

You will also need to ensure that your common directory is fully up to date. Run git pull from within the common directory to receive the latest updates.

Utilising the local repository

Solbuild has had support for local repos since its creation.

Improvements have been made to make it simple for contributors to test fixes out of the repo without having to wait for each patch to be merged. To include .eopkg files within a build, they need to be copied to the local repo directory /var/lib/solbuild/local .

Note that you will need both the regular package and the -devel package if you want to build another package against them using pkgconfig() in the package.yml file .

With the .eopkg files now present in the local repo, we can make use of them in solbuild by running make local rather than make . This will index the local repository and prioritise their use over what is available in the Solus unstable repository.

Best practices when working with a solbuild local repository

There are some important things to know when working with local repositories, as they may lead to issues later on.

• Solbuild will use your version of a package from the local repo regardless of whether there’s a higher release in the Solus repository. Therefore you should only use make local when required and also remove old packages from the local repo when no longer needed.
• If the package is already installed in the solbuild image, the release must be higher for it to be installed.

Eopkg and local repositories

As alluded to above, eopkg supports resolving packages from more than one repository.

In practice, this can be leveraged to make the developer workflow more convenient by ensuring that eopkg pulls from the local solbuild repository.

Generating an eopkg index for the local solbuild repository

Before packages from the local solbuild repository can be resolved, an eopkg index file needs to be created.

As mentioned earlier, the local solbuild repo installed by the solbuild-config-local-unstable package lives in /var/lib/solbuild/local .

To generate or refresh the eopkg index in /var/lib/solbuild/local , simply run:

sudo eopkg index —skip-signing /var/lib/solbuild/local/ —output /var/lib/solbuild/local/eopkg-index.xml

A note on package resolution priority

It bears repeating that in its current incarnation, eopkg will always prefer packages from the topmost repository listed with eopkg lr .

In other words, if a package exists both in the local solbuild repository and the official upstream Solus repository, eopkg will only consider the package from the first repository listed with eopkg lr regardless of its release number.

Adding the local solbuild repo to the eopkg repository database

The easiest way to add the local solbuild repo to the list of repositories known to eopkg is to add the local solbuild repo and then re-add the official Solus repo.

Checking the currently known eopkg repositories

But first, let’s list the repositories currently known to eopkg with eopkg lr – this should produce output similar to:

Adding repositories in the correct order

Now the repositories need to be added to account for the desired dependency resolution order:

This should yield output similar to:

Re-checking the currently known eopkg repositories

All that is left now is to check that the dependency resolution order is correct so that packages from the local solbuild repository are preferred over the upstream Solus repository.

Thus, eopkg lr should yield output similar to:

Disabling the local solbuild repository in eopkg

To reset the system to use packages from the official Solus repository exclusively, the Local eopkg repository can be disabled with the command sudo eopkg disable-repo Local .

The output should look similar to:

The Local eopkg repository can be re-enabled with sudo eopkg enable-repo Local .

Closing thoughts

Congratulations on making it this far! Your system should now be ready for convenient deployment and testing of locally built packages.

Note that packages not present in the local solbuild repository will be fetched from the upstream official Solus (unstable) repository.

Finally, keep in mind that the eopkg index needs to be refreshed whenever you add or remove locally built packages to your local solbuild repository – otherwise eopkg won’t know that new packages are available / have been removed from the repository.

Источник

Help Center

Get answers to common questions

Building a Package

This guide will walk you through setting up the file(s), tooling, and building your package.

Setting up Packager file

In order to utilise the build system, you must first set up a configuration file that has your packager details.

This file lives in the .solus folder of your home directory. You will need to create the .solus folder as well as the inner packager file. Inside the packager file, you need two keys, Name and Email . This is used when generating the machine file so that the packager details are stored within the resulting binary package.

Using solbuild

The solbuild tool must first be initialized with a base image. All builds thereafter will use this as a base, and construct a temporary overlay root to save on time and disk space in builds.

Initializing solbuild

First, install the system.devel component by calling: sudo eopkg it -c system.devel

Next, install solbuild itself with sudo eopkg it solbuild . If you are building against unstable, also install solbuild-config-unstable .

Next, you need to initialize solbuild via sudo solbuild init

This will take some time as it downloads and prepares the image. It is a good idea to update the root on a semi-regular basis, otherwise the updates will be applied on every build.

Updating solbuild

It is a good idea to keep the base image updated. It will help reduce build times by not having to repeatedly download updates to packages in the base image, and will strictly need to pull down the packages your build needs.

To update solbuild, run: sudo solbuild update

Setting up common

Next you need to set up common , a set of make scripts that enables you to more easily manage, build, check, and publish packages.

You need to clone the common repository with git by doing git clone https://dev.getsol.us/source/common.git in the same directory you will have sub-folders for packages you are building.

Next you need to set up symlinks. Do this from the same directory you executed the git command:

Next, inside the folder of the package you are building, run: echo «include ../Makefile.common» > Makefile

This will enable you to call make commands from inside the package folder.

Your folder should look something similar to this:

Building packages (Solus only)

After setting up common, you can now build the package. Note that build dependencies and such will be installed locally (in the chroot environment).

You will be prompted to enter your password by sudo so dependencies may be downloaded and the necessary eopkg files may be generated.

Источник

How to Use the eopkg Commands to Manage Packages in Solus Linux

Last updated July 10, 2020 By Dimitrios 6 Comments

As a distribution built from scratch, the number of packages available in Solus repositories is limited, unlike Arch-based distributions that have AUR. But Solus compensate it with the support for Flatpak and Snap packages.

The package manager for Solus Linux is eopkg which is based on PiSi (Packages Installed Successfully as Intended), the package manager developed for Pardus, a distribution based on Debian that has support from the Turkish government.

In this tutorial, I’ll show you some of the common usage of the eopkg that you can use to manage packages in Solus Linux.

Using eopkg package manager in Solus Linux

If you prefer to use a GUI application to manage the installed software, there’s a Software Center, that you can open from the menu. I’ll briefly touch upon it in later parts of this section.

Installing software

You can install one or more packages with eopkg in the following way:

Uninstalling software

You can remove one or more installed packages using:

Reinstalling software

If there is an issue with an installed software, you can reinstall the package using:

Search for an available package

You can search whether a package is available in Solus repository.

Notice that you don’t need to search for a specific software name, although you can do that. It search summaries and software names by default.

Get information on software (before or after installing them)

You can also get some additional information on a software, such as its description, version, installation size etc.

Updating a specific package or all of them together

You can update your system by using:

If you want to only update a specific piece of software on your system, you can specify is like below:

Third Party Applications

Solus has a Third Party Repository, it contains applications that cannot be included in the primary repository due to licensing issues.

Here’s a list of some of the applications available in this repository:

• Google Chrome
• Skype
• Slack
• Spotify
• TeamViewer
• Microsoft Core Fonts
• Android Studio

Snap and Flatpak for additional software

As mentioned earlier, Solus supports Snap packages. Commencing with Solus 3 and above, Snap is already installed and ready to go.

Flatpak packages

To install Flatpak, run the following command in the terminal:

To enable Flathub repository:

Restart your system, and you can install flatpak packages.

Bonust Tip: Installing LTS kernel in Solus

By default, Solus utilizes the Linux current kernel. If you run Solus on older hardware or stability is your priority you can install the LTS kernel as following.

Keep in mind that Solus still maintains the 4.9 LTS kernel (from 2016), not the latest 5.4 LTS.

To Install the LTS kernel, use:

By default, EFI installs will not show the boot menu and boot directly into Solus. By hitting space bar repeatedly during boot, the boot menu will appear.

After choosing the LTS kernel from the boot menu, use the following command to make the booted kernel the default boot option.

If you cannot access Solus in a dual-boot scenario, typically applies to “legacy boot” (non-UEFI), can be resolved by accessing the other operating system and running the following command:

Conclusion

Solus is a simple and reliable operating system. I’m a fan of the rolling release model and Solus user for quite a long time.

If you are not willing to dive deep into every Linux system parameter like you do with Arch Linux installation, then Solus is for you.

Snap and flatpak support won’t let you have limited software options, so it could be an ideal OS for the average desktop user as you won’t be bothered by point releases.

If you have tried Solus already please let me know your thoughts at the comments below.

Like what you read? Please share it with others.

Источник

Help Center

Get answers to common questions

Package.yml

All packages are generated from a single build file, which provides all of the required metadata for the package manager, plus the packaging steps involved to produce a package. This follows the YAML specification.

Format

All package.yml files must be valid YAML.

The file is organised into a key→value hierarchy. The ypkg tool parses a package.yml file to build the corresponding package in a declarative manner, so most of the keys are simple strings, lists or nested key→value pairs. A special case consists in the packaging steps, which are scripts.

An example file follows:

Not all fields in package.yml are mandatory, but a small selection are. Below is the complete list of the available fields.

Mandatory Keys

Key Name	Type	Description
name	string	The name of the package. This is also used as the base of all sub-package names. Unless unavoidable, this should match the upstream name.
version	string	The version of the currently packaged software. This is taken from the tarball in most cases.
release	integer	Specifies the current release number. Updates in the package number are based on this release number, not the version number. As such, to release an update to users, this number must be incremented by one.
license	string(s)	Valid upstream license(s). Try to ensure these use SPDX identifiers.
source	dict(s)	Upstream source URL (i.e. tarball), with the valid sha256sum as a value. Alternatively, the git repository URL prefixed with `git
component	string	Component / group of packages this package belongs to. Check available components via eopkg lc
summary	string	Brief package summary, or display name.
description	string	More extensive description of the software, usually taken from the vendor website.

Optional, supported keys

Key Name	Type	Description
clang	bool	Set to yes if this package benefits from being built with Clang.
extract	bool	Set to no to disable automatic source extraction.
autodep	bool	Set to no to disable automatic binary dependency resolution at build time.
emul32	bool	Set to yes to enable an -m32 build (32-bit libs).
libsplit	bool	Set to no to disable splitting of libraries into devel sub-packages.
conflicts	string(s)	Specify packages that cannot be installed together with this one.
optimize	list	Specify preset keys to modify compiler and linker flags during build. You can learn more here.
builddeps	list	Specify build dependencies for the package. You can learn more here.
rundeps	dict(s)	Specify further runtime dependencies for the packages. You can learn more here.
replaces	dict(s)	Replace one package with another, used when renaming or deprecating packages for clean upgrade paths.
patterns	dict(s)	Allows fine grained control over file placement within the package or sub-packages. Useful for packages that are development only (i.e. /usr/bin files).
environment	unicode	Specify code that will be exported to all packaging steps of the build (i.e. exporting variables for the entire build).
networking	bool	Set to yes to enable networking within solbuild.
homepage	string	Provides a link to the package’s homepage in the Software Center.

Packaging Step Keys, optional

The packaging steps are all considered optional, however the absence of the install step will result in no package generated. Each of these keys contains content that will be placed within a script and executed within a controlled environment to perform the package build. For all intents and purposes, they are Bash scripts with a predefined environment.

Step Name	Description
setup	Performed after the source extraction. This is the correct place to perform any configure routine, or to patch the sources.
build	Use this step to run the build portion, i.e. make
install	This is where you should install the files into the final packaging directory, i.e. make install
check	This is where tests / checking should occur, i.e. make check
profile	This is where profiling tests should be specified. ypkg will handle setting flags to generate profiling data and using that data for an optimized build.

Optimize values

One or more optimize values can be specified in a list with the optimize key in the package.yml file. Several values can override or conflict with each other and should be used only where they provide a performance benefit, or fix a bug in the package or build.

Optimize Value	Description
speed	Optimise the package for performance -O3 plus other flags.
size	Optimize the package build to minimize size -Os . Not supported with clang.
no-bind-now	Configure the package to disable certain flags, where RELRO is unsupported.
no-symbolic	Disable -Wl,-Bsymbolic-functions linker flag.
unroll-loops	Enable -funroll-loops . Use this sparingly, only when it provides proven benefit.
runpath	Enable -Wl,—enable-new-dtags to make linker use RUNPATH’s instead of RPATH’s.
avx256	Disables -mprefer-vector-width=128 in avx2 builds.
thin-lto	Enable Thin Link Time Optimization -flto=thin with a supported linker.
lto	Enable Link Time Optimization -flto .

Macros

To further assist in packaging, a number of macros are available. These are simply shorthand ways to perform a normal build operation. They also ensure that the resulting package is consistent. These macros are only available in our packaging steps, as they are substituted within the script before execution.

Usage

Macros are prefixed with % , and are substituted before your script is executed. Macros ending with % are used to provide directory names or build values, to the script.

Actionable Macros

Macro	Description
%autogen	Runs autogen with our %CONFOPTS% to create a configure script then proceeds to run %configure .
%cmake	Configure cmake project with the distribution specific options, such as prefix and release type.
%cmake_ninja	Configure cmake project with ninja so it can be used with %ninja_build , %ninja_install and %ninja_check macros.
%configure	Runs ./configure with our %CONFOPTS% variable macro.
%make	Runs the make command with the job count specified in eopkg.conf
%make_install	Perform a make install , using the DESTDIR variant. Should work for the vast majority of packages.
%patch	Sane patch macro to run in batch mode and not contaminate source tree on failure
%apply_patches	Applies all patches listed in the series file in ./files folder.
%reconfigure	Updates build scripts such as ./configure and proceeds to run %configure .

Haskell Actionable Macros

Macro	Description
%cabal_configure	Runs cabal configure with prefix, libdir, etc. and ensures the necessary package.conf.d is copied to the correct location.
%cabal_build	Runs cabal build with %JOBS%
%cabal_install	Runs cabal copy to $installdir
%cabal_register	Runs cabal register to generate a pkg-config for package and version, then installs the conf file.

Ninja Actionable Macros

Macro	Description
%meson_configure	Runs meson with our CFLAGS and appropriate flags such as libdir.
%ninja_build	Runs ninja and passes our %JOBS% variable. This macro obsoletes %meson_build.
%ninja_install	Runs meson install and passed the appropriate DESTDIR and %JOBS% variable. This macro obsoletes %meson_install.
%ninja_check	Runs ninja test and passes our %JOBS% variable. This macro obsoletes %meson_check.

Perl Actionable Macros

Macro	Description
%perl_setup	Runs Perl setup scripts Build.pl or Makefile.pl with the appropriate variable flags.
%perl_build	Runs Perl build scripts or attempts %make .
%perl_install	Runs Perl install scripts or attempts %make_install .

Python Actionable Macros

Macro	Description
%python_setup	Runs the build portion of a setup.py using python2.
%python_install	Runs the install portion of a setup.py, to the appropriate root, using python2.
%python_test	Without argument, runs the test portion of setup.py. With a .py script, execute the script with python2. With something else execute the command “as it is”. (More info)
%python_compile	Compiles *.py files using python2. This is only useful where the build doesn’t compile them already (indicated by availability of *.pyc files).
%python3_setup	Runs the build portion of a setup.py using python3.
%python3_install	Runs the install portion of a setup.py, to the appropriate root, using python3.
%python3_test	Without argument, runs the test portion of setup.py. With a .py script, execute the script with python3. With something else execute the command “as it is”. (More info)
%python3_compile	Compiles *.py files using python3. This is only useful where the build doesn’t compile them already (indicated by availability of *.pyc files).

Ruby Actionable Macros

Macro	Description
%gem_build	Runs gem build.
%gem_install	Runs gem install with the appropriate parameters.

Qt Actionable Macros

Macro	Description
%qmake	Runs qmake for Qt5 with the appropriate make flags.
%qmake4	Runs qmake for Qt4, as well as adding the necessary MOC, RCC, and UIC flags since those Qt4 executables end in -qt4.
%qml_cache	Compiles *.qml files into *.qmlc so they are compiled ahead of time.

Waf Actionable Macros

Macro	Description
%waf_configure	Runs waf configure with prefix.
%waf_build	Runs waf and passes our %JOBS% variable.
%waf_install	Runs waf install and passed the appropriate destdir and %JOBS% variable

Variable Macros

Macro	Description
%ARCH%	Indicates the current build architecture.
%CC%	C compiler
%CFLAGS%	cflags as set in eopkg.conf
%CONFOPTS%	Flags / options for configuration, such as —prefix=%PREFIX% . Full List.
%CXX%	C++ compiler
%CXXFLAGS%	cxxflags as set in eopkg.conf
%JOBS%	jobs, as set in eopkg.conf
%LDFLAGS%	ldflags as set in eopkg.conf
%LIBSUFFIX%	Library suffix (either 32 for 32-bit or 64 for 64-bit)
%PREFIX%	Hard-coded prefix /usr
%YJOBS%	Job count without -j as set in eopkg.conf
%installroot%	Hard-coded install directory
%libdir%	The distribution’s default library directory, i.e. /usr/lib64 (Alters for emul32 )
%version%	Version of the package, as specified in the version key.
%workdir%	Hard-coded work directory (source tree)

Variables

A set of variables are exported in our build stages. These are used to provide context and structure to the scripts.

Variable	Description
$CFLAGS	cflags as set in eopkg.conf
$CXXFLAGS	cxxflags as set in eopkg.conf
$LDFLAGS	ldflags as set in eopkg.conf
$CC	C compiler
$CXX	C++ compiler
$EMUL32BUILD	Set only when compiling in emul32 mode
$installdir	The install directory, i.e. where files are installed to for packaging
$pkgfiles	Refers to the ./files directory relative to the package.yml file
$sources	Refers to the directory where your source files are stored e.g. $sources/nano.tar.gz
$workdir	The work, or source, directory of the package build

Types

The package.yml file uses native YAML types, however it follows syntactic conventions and may accept multiple value types for a given key.

string

This is simply text, which does not need to be quoted.

string(s)

Indicates that it is possible to use a list of strings, or one single string .

integer

Whole, positive number, used in the release field.

A YAML list (or array) can be expressed in multiple ways. A short array-notation would look like this:

They can also be expressed like this:

Known as an associative array, this is key to value mapping. These are separated by a colon ( : ), the token on the left is taken to be a key, and the token on the right is the value.

SomeKey: Some Value

Note that each ypkg key in the YAML file is actually a dict.

dict(s)

dict(s) consists of a list of dict s and some assumptions. We primarily make use of this to express advanced information within the package. These permit you to provide no key, and a value only. In this instance, the key is implicitly assumed to be the package name (e.g. nano ):

An explicit key, usually a sub-package name:

The values may also be expressed in list form, still using the same default key logic:

Источник