Providers and virtuals are concepts we use in Exheres in order to make the usage of packages which provide applications, libraries, etc., that are of the same general functionality easier in terms of packages’ dependencies. This documentation will attempt to dispell some common misunderstandings about the two concepts, and hopefully make it easier in the future for people who wish for more options to be available, to do so without much issue.
Users often want a choice; considering Exherbo is a source-based distribution, we should provide a choice when it makes sense to.
Providers are likely one of the best examples of the choices that users gain the ability to make with source-based distributions, because it eschews the idea of hard-dependencies on certain programs in favor of making packages depend on things for the libraries and programs they provide. It promotes diversity within the system as well, and reduces the likelyhood of a monoculture when it comes to the programs people use.
Not all users want to use
libav, so we delegate that choice to providers, by allowing users to specify it as options
*/* providers: -ffmpeg libav
And all packages which can use either would be smart enough to know what the user wants to compile with. There’s no arbitrary dependency on a certain program’s version of the ABI, and there’s no need to edit every single package to account for that dependency, as it is on some other distributions.
Virtuals are a subtly different beast. Virtuals are used when it is possible to replace a package (ex.
mysql) without much issue concerning ABI or linking.
pkgconf. Both provide a
pkg-config binary which are generally compatible, with each other. Almost all programs will do just fine with
pkgconf if they do fine with
pkg-config. Therefore, we allow users the choice between the two, and don’t make packages depend on one of them unless it is absolutely needed.
This means that users gain the ability to put things in their
*/* providers: -pkg-config pkgconf
and then, any package which requires
pkg-config can look to
DEPENDENCIES=" build+run: virtual/pkg-config "
virtual/pkg-config lists in its dependencies
DEPENDENCIES=" build+run: providers:pkg-config? ( dev-util/pkg-config ) providers:pkgconf? ( dev-util/pkgconf ) "
and the author of the package which needs
pkg-config doesn’t need to care about it.
The virtual satisfies the dependency for that package accordingly, and users are free to change the provider as they please.
Packages such as
graphicsmagick both provide similar ABIs, and for the most part are compatible, but they require different libaries to be loaded, may provide different APIs, and aren’t going to be entirely compatible. This is why there is not a
virtual/imagemagick package; they are not compatible.
Virtuals can be useful when the provider isn’t a hard dependency of the package requiring it (via linking, or using APIs that are specific to an implementation of a library), but in most other cases they are not a good idea.
In these cases, coming back to the
imagemagick example, you’d want to use providers without virtuals instead.
media-gfx/inkscape has support for both and can be configured for whichever at compile time, therefore a user can specify in their
media-gfx/inkscape providers: -imagemagick graphicsmagick
media-gfx/inkscape will list in it’s options:
MYOPTIONS=" ( providers: graphicsmagick imagemagick ) [[ number-selected = exactly-one ]] "
and it does what you’d expect it to do.
libcimplementations? glibc, musl, etc
libstdcvia virtuals?; GNU’s libstdc++ vs. LLVM’s libc++.
Copyright 2015 Kylie McClain