Re: setup and 'provides:'

[Ken Brown <kbrown at cornell dot edu>]

On 10/9/2018 11:10 AM, cyg Simple wrote:
> On 10/8/2018 12:24 PM, Ken Brown wrote:
>> On 10/8/2018 11:17 AM, cyg Simple wrote:
>>> On 10/8/2018 11:05 AM, Ken Brown wrote:
>>>> 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?
>>
>> They use different names for the emacs binaries: emacs-nox.exe,
>> emacs-X11.exe, emacs-lucid.exe, and emacs-w32.exe.  The "alternatives"
>> system then creates a symlink /usr/bin/emacs that resolves to whichever
>> binary the user wants to use by default.  It's been this way for many
>> years, with no problems.
>>
> 
> I assumed that this was the case.  But the symlink is a conflict and I
> assume that if one exists already the package management system would
> not recreate one or would ask the user if it should be overwritten.

No, that's not how it works.  The symlink is created and managed by the 
alternatives system via commands in postinstall/preremove scripts and in 
user-callable scripts /usr/bin/set-emacs-default-*.  There is no conflict.  The 
various emacs packages can happily coexist.

>>>> 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?
>>
>> "emacs-bin" is not a thing that can be installed.  It's simply a name
>> for a requirement, and that requirement can be met by installing any
>> package that declares that it provides "emacs-bin".  At least that's my
>> understanding of how it works in package managers like rpm.  As I said
>> at the very beginning, it's quite possible that I'm misunderstanding how
>> 'provides:' is supposed to work.
> 
> And I understand that emacs-bin is a pseudo name identifying a class of
> product the package provides.  The RPM system allows for defining
> Requires, Provides, Conflicts and Obsoletes.

So does Cygwin's setup.

>  The Arch Linux pacman
> allows for depends, makedepends, checkdepends, optdepends, provides,
> replaces and conflicts.  As you can see other package managers see
> *conflicts* as an important item because of the global namespace issue.

I agree that it can be useful, and I'm glad setup supports it.

Ken