On which distribution is vanilla based?¶
On which package manager is vpk based?¶
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 criterias (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.
- You want to install your very own zlib version (not even from vanilla sources)
- You download, install zlib by yourself (making sure it's ABI compatible)
- You mark the zlib package as installed (with the
vpk mark zlib owncommand upcoming)
- You install a package from vpk that depend on zlib, it does not complain and think it's installed
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.
For the moment, it's not implemented in
vpk yet but it will probably look like:
# /etc/vpk/excludes.conf /include /share/info /share/man
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 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.
I can't find SDL2, libssh2 or other packages like that?¶
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. E.g.
vpk search libssh should bring you two versions
libssh0 (which is libssh) and
libssh (which is libssh2).
Is there a kind of AUR/COPR/PPA service in vanilla?¶
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 stuff).
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.