Conflicts vs Provides

vixalien

In the 66 README, the Roadmap section mentions:

Provide a Conflicts keyword at frontend file:
Allow to declare a conflicting service through the Conflicts field, e.g. connmand service will declare Conflicts = ( Networkmanager ).

But this seems a bit bizarre. I think Provides would be a better option. For example, in openrc, both connmand, networkmanager, networking and others would provide net. By the default alpine policy for example, networking provides net and you can easily switch to it by enabling networkmanager and disabling the other. This means that other services just need to depend on net and not care about the implementation.

Other examples off the top of my head could be chrony providing ntp-client and ntp-server. gdm providing display-manager and more.

eric

It's not exactly the same things. Conflicts avoid to activate two services which make the things (networkmanager - connmand). So, user will not be able to do 66 enable networkmanager if connmand is already enabled.
Provides make some sort of Alias.
Anyway, both features are needed.
I also like the pacman way doing the third keyword: provides, conflicts, replaces.
It is not a easy feature to add because this touch some sensible part of the code .

vixalien

I would like to think that in the specific case of network manager above, a Provides would be better right? Because otherwise the unit file for network manager would need to explicitly say it conflicts with conmand, networking, and others

pramodvu

Provides= will basically declare a generic alias.
It can easily solve the problem which Conflicts= is trying to solve, like NetworkManager and conmannd
However, Conflicts= would be a good option for those daemons conflicting with other random daemons.

As for Replaces=(), it is NOT what I would recommend, as then if NetworkManager and ConMannd both replace each other,...back to square one - waste of programming effort. If only conmannd Replaces=(NetworkManager), then... "Why is 66 changing my neteworking daemon without asking?" - This problem can be solved only by NOT replacing...then why is it there?
A daemon which replaces another will ALWAYS conflict, but the other way around is not ALWAYS.
Provide=() and Conflicts=() will give a much more flexible and logically simple setup for what Replaces=() would.

eric

This feature is not so evident to implement.
Let’s imagine we do something like this for networkmanager and connmand:

[Main]
...
Provides = ( network )
...
[Start]

1.First at all, when is the alias applied? At runtime or parse time?

Suppose both frontend files, networkmanager and connmand, are present on the system. When I execute 66 start network, which one does 66 pick, networkmanager or connmand? If the choice is made automatically, the user might not be aware of the selection.
How can we let the user decide which one to use? How can this be implemented?
How does the user see where the alias points?
How the user can change the target of the Alias?

pramodvu Provide=() and Conflicts=() will give a much more flexible and logically simple setup for what Replaces=() would.

Agreed, the replaces is not necessary and bring more complexity without benefit.

Let say that the Provides key is made at parse time. Now, i do 66 enable networkmanager, a symlink call network will be created. Then i can do 66 start network. Now i do 66 enable connmand. What happen to the symlink? If i decide that the latest enabled service take precedence, when i enable connmand the network symlink is replaced and point now to the connmand service. So far so good but my networkmanager service is always enabled. So conflict here. That mean that Provides need to automatically add Conflicts, so when i do 66 enable connmand, the networkmanager need to be disabled automatically.

pramodvu

eric Suppose both frontend files, networkmanager and connmand, are present on the system. When I execute 66 start network, which one does 66 pick, networkmanager or connmand? If the choice is made automatically, the user might not be aware of the selection.

For this, exit with an error. That's it. Ask to user to select it. Say that the network service has conflicting providers.

eric .First at all, when is the alias applied? At runtime or parse time?
At time of enablement of NetworkManager or conmannd. If neither is enabled and the network service is started, then 66 should complain of conflicting providers, and ask the user. Preferably give the user a list of providers.

eric How can we let the user decide which one to use? How can this be implemented?

Just let the user enable his service.
Again, if none is enabled, exit with error... asking the user.

eric How does the user see where the alias points?

66 status network or whatever command-line interface.

eric How the user can change the target of the Alias?

66 disable conmannd && 66 enable NetworkManager
This way, things are simple.

eric Let say that the Provides key is made at parse time. Now, i do 66 enable networkmanager, a symlink call network will be created. Then i can do 66 start network. Now i do 66 enable connmand. What happen to the symlink? If i decide that the latest enabled service take precedence, when i enable connmand the network symlink is replaced and point now to the connmand service. So far so good but my networkmanager service is always enabled. So conflict here. That mean that Provides need to automatically add Conflicts, so when i do 66 enable connmand, the networkmanager need to be disabled automatically.

The one created earlier should be the dominating one. User will disable NetworkManager himself and enable conmannd if he needs alternate networking. This will reduce the possibility of changes done out of user's knowledge.

In your case, 66 enable conmannd will exit with error, informing the user.

But if neither is enabled and 66 start network is called, exit with error saying that network has conflicting providers.

OR
Support them as 'virtual'/'provider' services, with special options or commands. This is overly complex for you to support, so...

eric

pramodvu This way, things are simple.

you're right.

pramodvu The one created earlier should be the dominating one.

i agree too.

@vixalien
Thanks for this information. Note, please take of the markdown format when you post.

vixalien

66 enable network
Actually, on OpenRC atleast, this won't work. I can't enable virtual services, nor list them. See the following

$ cat /etc/init.d/networkmanager -p
#!/sbin/openrc-run
# Copyright (c) 2008 Saleem Abdulrasool <compnerd@compnerd.org>
# Distributed under the terms of the GNU General Purpose License v2
# $Header: $

supervisor=supervise-daemon
command=/usr/sbin/NetworkManager
command_args_foreground="-n"

description="Network Manager Daemon"

depend() {
   need dbus
   provide net
}

# vim: set ft=gentoo-init-d ts=3 sw=3 et:

$ service net status
 * service: service `net' does not exist

$ service networkmanager status
 * status: started

So you can see that OpenRC says net doesn't exist even though networkmanager does exist and is started. The only use for Provide= is when other services need a service, but don't care about the implementation. For example, rsyncd, chronyd, mdnsd, rdate, etc... depend on net, and will not be run when net is not started (successfully).

pramodvu

vixalien

If on an openrc system networkmanager and connmand are installed, what happens?

If rsyncd, chronyd, etc.. on a 66 system want networking, then they depend on Network, without worrying about the implementation.
This means that NetworkManager and ConnMand are interchangeable. This is another advantage of Provides=

However, 66 can have support for showing the backends for a provider with 66 status Network, instead of just erring.

vixalien

eric Note, please take of the markdown format when you post.

Sorry, I have now edited my post and it should be much more readable.