On 10/8/2018 11:05 AM, Ken Brown wrote: > On 10/8/2018 10:41 AM, cyg Simple wrote: >> On 10/7/2018 6:02 PM, Ken Brown wrote: >>> I've been experimenting with setup's support for the 'provides:' tag, and >>> it's >>> not behaving the way I expect [*]. I'm not sure if something in setup's >>> interface with libsolv needs to be tweaked or if I'm just misunderstanding >>> how >>> this should work. Here's what I tried: >>> >> >> Shouldn't there be a need for a 'conflicts:' tag as well? > > setup does support a 'conflicts:' tag, but I don't see why I should need > it here. >
You might not, others might. See below ... >>> I created a test repo with packages A, B, and C. I made A require foo (not >>> a >>> package), and I made B and C provide foo. The attached script does all this >>> [**]. I then ran setup and selected A for installation. >>> >> >> So C:foo conflicts with B:foo. > > I'm not sure what you mean by C:foo and B:foo. My intention is that > "foo" is an identifier for a single requirement, which can be provided > by B or C or both. I explicitly want to allow both to be installed, so > I don't want B and C to conflict with one another. "A single requirement" is the issue. B and C both provide foo but the foo in B and C are different and conflict with one another so which one is correct to satisfy the package A requirement? > > Here's an example (modeled on what Fedora does): Cygwin has four > packages that provide emacs binaries: emacs, emacs-X11, emacs-lucid, and > emacs-w32. Users can install any or all of these if they want to be > able to run emacs. The differences are in the UI. These packages don't > conflict with one another. > How do they overcome the conflict? > If some other package requires an emacs binary, I would like it to be > able to require "emacs-bin". [This plays the role of "foo" in my test > case.] Then I would like to be able to say that all four emacs packages > above provide "emacs-bin". > That's fine but how do an installation of multiple emacs-bin not create a conflict? >>> The result was that libsolv simply chose B for installation, and setup >>> showed >>> this in the "Confirm" dialog. What I expected was that libsolv would >>> report a >>> problem ("A requires foo but no selected or installed packages provide it"), >>> with two possible solutions ("Install B or C"). Is that expectation >>> unreasonable? >>> >> >> Not unreasonable but what happens if B:foo is already installed and >> C:foo is the required because the functionality is slightly different? > > See above. You're above didn't answer the question. -- cyg Simple