sakuglen cassidy janneta
Tamela
My previous article (Demystifying UEFI) had an outstanding response. It became the top post of the month on r/embedded and even made it to the top 10 of the year. It was even recognized by Google Discover, which I myself received as a recommendation, showing me the positive impact it had. So, I am grateful to everyone who found value in my last article.
The reason is simple, its by far its the most scripted distro I ever seen. See everybody likes using ready-to-use products, but as you move with them you feel to lose control over your environment (things break if you try to swap components), feel restricted and hence unproductive. But if you choose minimalism, getting things done becomes very tedious and time-consuming.
Since I started using void, I learned quite a lot, and it had let me swap almost every single component without ever breaking my installation. And I'm going to unravel everything I know about Void Linux.
One of the greatest advantage of this build-system unlike others is that none of the builds interfere with the host system, everything happens under the isolated chroot, and final build gets packaged into a *.xbps binary file in hostdir/binpkgs directory.
Unlike AUR where each package is splitted into different repositories and everything depends on owner of that package, Void uses just a single repository void-linux/void-packages for every single package.
This means rolling release (shipping latest-versions) while being completely stable. It even tracks the common/shlibs to map libraries to pkgs, so it can perform partial upgrade without breaking anything (unlike Arch xD).
PS: Now this is controvertial as seen by reddit comments, its actually a personal taste if everything should go in one repository or not, but having multiple people verify the package status over different machine / architectures before its merged and distributed is a good to have.
Void in 99% of cases ships vanilla configurations. Only in terms of optional simplicity it ships with extra items such as global pipewire & wireplumber service (for audio), as its not shipped by the owner and also because its initially also tedious to set them up per-user basis.
PS: Note that xdeb is not official way of installing softwares, prefer making package templates under xbps-src if possible. xdeb doesn't perform a lot of checks that should be done to keep safety of void installation, it does however automatically detects dependencies so I showed it for quick reference.
This is not the end, it goes even further. I did not even touch upon other scripts such as xmirror - Fast CDNs, xbps - the package manager itself, more over runit (stages), the musl libc, etc. to keep the article short and crisp.
If you want you can go further down the rabbit-hole and be complete guru of linux, without wasting much time in LFS, while still getting what LFS can offer (source-based complete control), Void is probably going to be one of the best bet available for you!
Alot of helper scripts are life-saver, if anything goes bad, even deletion of /etc, you can rescue that (with xetcchanges), there's a complete control over the distribution, and hardly any risk is involved at any point of time.
While not delving into its technical features, I did want to experiment with xbps-src as it is one of the cornerstone features of Void that make it unique and worth using for a non casual user. At first, I chose to package Firefox Developer Edition, a program that isn't available from Void's free or non-free binary repositories. It is also not available in Void's source Github repository, a large component of Void's source package management system. On distributions where FDE is not available, I typically use a script based on Installing Multiple Versions of Firefox Including Multiple Profiles to install it. In this case it was a perfect candidate, besides Kmail built for Plasma 5 -- which would be too complicated for a first attempt, with which to try xbps-src.
Unfortunately, this attempt was not successful because, although Void is rolling, it is not bleeding edge as far as Mozilla associated packages are concerned (see below), and a recent enough Mozilla dependency was not available. So I thought Opera Developer would be a simpler alternative. Again, this had an obsolete dependency (see below), which I think is a fault of Void, whereas the FDE complication may not be.
In order to use xbps-src and its associated tools, the system has to be prepared.XTOOLSThe xtools package provides some useful utilities specifically for xbps-src and some that are generally useful. It can be installed with:sudo xbps-install xtoolsVoid Linux Github RepositoryThe core of Void's method of organizing source packages directories, build directories, and associated build system paths is a clone Void's Github repository of source packages. The clone can be created on the local system -- for local use, not for contributing to Void -- with:git clone -packagesThis will create the directory void-packages with the source tree of all Void packages in void-packages/srcpkgs. The following representation of void-packages is reproduced from the Github repository's README. /void-packages - common - etc - srcpkgs - xbps - template - hostdir - binpkgs ... - ccache- ... - distcc- ... - repocache ... - sources ... - masterdir - builddir -> ... - destdir -> ... - host -> bind mounted from - void-packages -> bind mounted from Some of the Directories Under void-packages Then install the bootstrap packages, which are required to build the binary packages in isolation, with the following:cd void-packages./xbps-src binary-bootstrapThis installs the binary bootstrap packages; if the user desires building the bootstrap packages themselves, bootstrap can be used instead of binary-bootstrap.Void uses some utilities -- two that are part of XBPS and one that is not -- to manage the chroot and bind mount of the build environemnt. I chose the xbps-uchroot utility. In order to enable it, I executed:# cd /usr/bin/$ echo XBPS_CHROOT_CMD=uchroot >> etc/conf# chown root:xbuilder xbps-uchroot# chmod 4750 xbps-uchroot# usermod -a -G xbuilder brook
(adsbygoogle = window.adsbygoogle []).push();After preparing the system as above, for at least building for local installation -- not for contributing changes to the Void repos -- we are ready to build some packages. The basic steps I used are to first make the template. This is the script that provides the build "recipe" as does RPM distributions' .spec file, Arch's pkgbuild, and Gentoo's .ebuild. One of the xtools utilities can create a skeleton template with some prepopulated fields with:xnew opera-developer
- Void's Opera Template and the xnew Generated Opera Developer Template
- Browsing Opera's Source Package RepositoryBrowsing Opera's source package repository to determine the appropriate value for the template's distfiles parameter. Opera's repository is much more simple than Mozilla's very complicated unified Mercurial repository that hosts FDE's source packages.
- The Opera Template and the Completed Opera Developer Template
The same series of commands used as for Opera Developer will build the Firefox Developer Edition binary.xnew firefox-developer-editionxgensum -f srcpkgs/firefox-developer-edition/template./xbps-src pkg firefox-developer-editionAfter creating the skeleton template with the xnew command, using the template for the Void packaged Firefox as a guide, I modified it with appropriate changes, most importantly the very different URL used in the distfile parameter due to fewer available options for obtaining the FDE source packages. The final version of the template I used is available here.
- Enlightenment First Run Settings
Sadly in both of my attempted builds, there were unresolvable problems. In the case of Opera Developer, the build completed successfully, but the package could not be installed due to an unresolved dependency on rpi-userland>=0.0.0.0.20150907_1. This dependency, to my knowledge was not created by the Opera source package, and it certainly was not required by the template itself, but by void-packages/common/shlibs.
In the case of Firefox Developer Edition, the template I used as a guide, the Firefox template in Void srcpkgs, indicates an nss of version >=3.35, which is also the version available in Void srcpkgs, however it seems that Mozilla requires version >=3.36.1 for this version of FDE, and late in the build process there is an error indicating that the nss is not installed or the version is too old. There was no problem, however, with the build time dependency of the nss development package.
Although the builds were not successful, this experiment instilled a very positive impression of the xbps-src program itself. However, some of the infrastructure, such as the one with void-packages/common/shlibs which creates a systemwide dependency on an obsolete package, and the lack of a current nss by Mozilla standards, was dissapointing.
A. License from X. Subject to your compliance with the terms of this Agreement and the applicable Incorporated Developer Terms, X hereby grants you a non-exclusive, royalty free, non-transferable, non-sublicensable, revocable license to solely:
c01484d022