On which distribution is Vanilla Linux based?¶
On which package manager is vpk based?¶
Is vpk Linux-only?¶
vpk tool has busybox as unique dependency so it runs on any system that supports busybox unless some applets are not available on this platform.
And is Vanilla Linux-only?¶
At this time of writing, yes. But several packages do not require a Linux kernel at all. This means that several packages could even be built on other platforms such as *BSD, Minix or perhaps Haiku. On the other hand, some packages are not directly compatible with musl and such packages are patched to build with musl. But most of those patches are only removing assumption of being ran on a glibc based system and could probably work with other systems as well.
Keep in mind that both vpk and Vanilla are made portable in mind and we'd be glad to see a non-Linux variant of Vanilla!
Are there major upgrades within release versions?¶
Short answer: no.
We keep libraries and tools at a specific fixed version within the same release. However, we may perform minor upgrades of several packages that are known to be stable enough and as long they are ABI compatible and do not introduce a behavior change. But a release is still be maintained as bugfixes in the most of the cases.
Why weak dependencies?¶
Many Linux distributions use strong dependencies which prevent users for replacing parts of the system by yourself. Some well designed packages manager depend on specific criteria (having a file or library) rather than a specific package itself though. I believe it's simpler to depend on a package and install it by default but let the user install it by itself if required.
With the upcoming attribute system in
vpk tool you will even be able mark a package installed while you didn't install it with vpk at all.
I don't want development files¶
In Vanilla, packages are not split. While in most popular distributions you have the runtime (e.g. libzip), the development files (e.g. libzip-dev(el)) and eventually documentation or debug information (e.g. libzip-doc and libzip-dbg), Vanilla packages include all. This is convenient for developers but may be useless for simple users. It facilitate the development of new packages for Vanilla at the cost of taking more space on the disk. This is more true on embedded devices where we want to use less as possible space on the hardware.
Instead of creating subpackages for that purpose, Vanilla use a different approach and allows the exclusion of files during installation and since all packages use the same directories it's easy to exclude those files.
Note: this is not implemented yet but planned.
Linux Standard Base (LSB for short) is an old reference that defines a set of recommendations for all distributions. While useful for major distributions, it is too rigid and recommends lots of things that we don't use or are not applicable. For example, LSB requires libstdc++, libgcc_s and many others. Also, it recommends a very old and archaic Filesystem Hierarchy Standard that Vanilla Linux explicitly cleanups.
Installation of packages is slow!¶
Yes. Unfortunately this is a side effect of being based on pure shell. Fortunately, you usually don't have to update dozen of packages everyday.
Why is gtk 3.0 package named gtk?¶
Be aware that Vanilla has a different package naming scheme than most distributions. Packages in Vanilla are usually named without version suffixes for the highest available version even if some packages have forked and no longer have the same origin or are completely independent. We believe that the newer version is meant to be the standard upstream while previous versions are meant to be deprecated and removed at some point.
For example, this means that GTK 2.0 is effectively named
gtk2 while GTK 3.0 is named
gtk. Then, once GTK 4.0 is released, the package
gtk will be renamed to
gtk will refer to the 4.0 version. As a recommendation, always search the canonical name of the package you want to install.
However, if the package itself includes a number in its name (e.g. libssh2, nghttp2, SDL2) we do keep this number as part of the package name.
Is there a kind of AUR/COPR/PPA available?¶
No and there won't be one.
While decentralized stuff is a good thing it's not the best way to improve a distribution. Instead we encourage people to provide patches to incorporate more packages into Vanilla especially since there is no much restriction on what is added to the repository (except non-free packages).
Also in the example of AUR, there is absolutely no security check regarding what users put in it. Thus, we don't want Vanilla to be associated with broken “community” packages or even worse if people destroy systems by mistake.
For closed-source software, since Vanilla embrace the opensource we may only advise to not use them at all. More importantly, most of the proprietary programs that are available for Linux are usually built upon glibc/gcc/libstdc++ and therefore are de-facto non compatible with Vanilla.
Note: it's still possible to install packages from anywhere using the
vpk add command which does not handle dependencies and use local package files though.
I want multiple repositories!¶
While convenient, multiple repositories is a very complex thing and not implemented.
Let say you want to install package foo, but this package is provided in multiple repositories. Then we will need either to prompt the user to select the desired one, but for some reasons the selected package conflicts with some of the system then we have a very hard and frustrating issue.
Remember that Vanilla is meant to be a small distribution and contributions are fairly easy so we hope that you will bring your package into the main Vanilla repository.
I prefer GCC over LLVM/Clang¶
The purpose of Vanilla Linux is to make a complete Linux distribution with only LLVM/Clang as its best and therefore not best suited for people who prefer gcc. That said, the package
gcc is available as alternative but not installed by default and will always be provided in the repositories.
It's technically possible to rebuild the whole system using gcc rather than clang but requires some efforts and rebuild all packages. I suggest starting with the minimal rootfs image, deinstall all LLVM packages (libc++, libc++abi, libunwind) and then start rebuilding all packages.
Don't forget to set
CC=gcc and CXX=g++ before calling
Note: at this time of writing, mesa package requires LLVM and links to other LLVM libraries which could create ABI incompatibilities.