Description of problem:
I drew up a whole plan about how to use direct soft dependencies (Recommends, Suggests) in order to achieve the desired effect for a bunch of related packages.
But then I found out that nobody knows whether use of soft dependencies in current Fedora is forbidden or not.
Basically, I want precise information about how dnf supports soft dependencies so I can make the decision of whether to take the time to implement or improve my plan
or whether my time is better spent figuring out some way to achieve close
to what I want with hard dependencies and a bunch of meta-packages.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
The plan, as far as it went:
1) For libblockdev:
- Add Recommends: <plugin> to libblockdev package forall <plugin>s
that have a subpackage in libblockdev.
* The expected result is that when libblockdev is installed all these
plugins will be available and so will be pulled in. However, it is
possible to specifically exclude packages via command line or config
file. If a plugin package is excluded then there will be no error
and installation of libblockdev will still proceed but without that
plugin and its dependencies (so long as nothing else requires them).
* There are a few ways to do this:
- Make plugins-all meta-package Recommend rather than require
every plugin. Leaves Requires: libblockdev in there.
- Get rid of plugins-all meta-package and have libblockdev package
Recommend: all plugins.
* Later maybe libblockdev plugin versions will diverge from libblockdev
versions. This can all still be handled in libblockdev spec file.
* Still later may be alternative plugins that are not part of standard
libblockdev distribution. These can have reverse dependencies
of one sort or another on libblockdev.
2) For blivet:
- Require the libblockdev package or metapackage or whatever (see 1) that
recommends the libblockdev plugins _and_ requires libblockdev itself.
- Suggest a whole bunch of packages that correspond to those that
are not currently required by blivet but have external
resource objects listed in availability.py file (because blivet
does need them in some situations).
- Recommend dosfstools (it is currently required). Another option
is Suggest, a little more dramatic but I think preferable. That
option is discussed below.
- Continue to require e2fstools. It supports blivet's default
* The expected result is that when blivet is installed it will
get libblockdev with all the plugins that were not excluded
when libblockdev was installed. Of course, a knowledgeable user
could do the whole install in one go, excluding plugin packages
as necessary. The use of Suggests will simply cause the suggested
packages to be slightly more favored when solving dependencies
for other packages. However, it will allow to keep versioning
information if necessary. dosfstools will generally be installed,
but if it is absent blivet can still be installed.
3) For anaconda:
- Do nothing at all.
4) For blivet-gui.
- Do nothing at all.
* The expected result is that things will go on much as before _except_
that dosfstools is no longer required by blivet and therefore not
transitively required by anaconda. How does anaconda feel about the
possibility of getting a blivet without dosfstools?
An alternative is that blivet suggest dosfstools and that anaconda/blivet-gui require it.
I believe that in that case, the suggested version will be used to guide the version
required, but I have not seen anything specific about that in any documentation.
I like this approach a lot better than recommending dosfstools.
What I read are three different questions/requests. The answer to whether or not to use soft deps is that they are supported throughout the rpm stack and it is possible to use them. The decision is up to you as a maintainer. We (as in Software Management Team) are drafting some guidelines with examples of problems that soft deps use.
The second question I can see is about support in dnf. Dnf itself has only a little to do with soft deps, most of the magic happens deep underneath in libsolv library. This library generally supports the semantics as described here:
On top of that, it is possible to use soft deps as a preference indicator when a certain requirement of your package is provided by more other packages.
From what I can read in your comment, your expectations as to how soft deps will behave are quite correct. How you use them is entirely up to you, we have only a little authority to limit that. That being said, I can give you one recommendation as a former active package maintainer - I'd avoid using metapackage in this case, as it obscures the relations between packages. Instead I'd use Recommends directly in libblockdev.
The third question, or rather request, that I can see in the description is how exactly does dependency solving work wrt multiple providers and soft deps. Like I said, you can use soft deps as preference indicator. I just run some tests and they work just fine ... which can't be said about versioned provides which don't seem to be working at all. So at the moment, I can confirm that soft deps beat versioned provides. If you need more detail on this, feel free to ask.
If you run into any troubles, please use one of our mailing lists instead of bugzilla. We have recently created firstname.lastname@example.org which is a perfect place for discussing cross project features such as this one. For the moment, I'm closing this as NOTABUG ...
Just to be sure, are we talking about "soft" dependencies or "weak" dependencies? AFAIK, "weak" deps (only mentioned in the summary but not in any of your comments) are e.g. the Suggests: and Recommends: tags while "soft" deps (mentioned a lot in your comments) is e.g. the "or" relation.
What you're talking about are rich dependencies. Soft dependencies and weak dependencies are just two names for the same thing.