| Summary: | [weak deps] No clear statement about whether soft dependencies should be used or not | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | mulhern <amulhern> |
| Component: | dnf | Assignee: | Packaging Maintenance Team <packaging-team-maint> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | jsilhan, jzeleny, mluscon, packaging-team-maint, pnemade, rholy, tla, vmukhame |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-05-14 08:34:55 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | ||
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: http://rpm.org/wiki/PackagerDocs/Dependencies 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 rpm-ecosystem@lists.rpm.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. |
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): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: 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. - Others... * 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 filesystem type. * 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.