I can attest that the reaction is justified. I would not like to have any Avahi in my datacenter. It can cause a myriad of issues in enterprise scaled enviroments (read thousands of servers).


On 4 Dec 2014 17:35, "Stef Walter" <stefw@redhat.com> wrote:
On 04.12.2014 16:22, Frank Ch. Eigler wrote:
>> [...]  Can we have /usr/lib64/libpcp.so without an Avahi dependency?
>> Or should we treat PCP as an optional dependency of Cockpit and
>> structure our code so that PCP is more of an add-on, used when
>> available?
> Can we dig a little deeper?  avahi-libs by itself is tiny (<200K); is
> its "Require: avahi" part the only problematic aspect?  In Fedora20+
> that's already gone (BZ913168); maybe that simply needs to be
> backported to RHEL*.

For starters, you can see the reaction of a system administrator to
Avahi in that bug. I make no comment on whether such a reaction is
justified or not.


So there are two reasons here:

 * We don't want a hard dep on "Avahi" to be a mental barrier to having
   Cockpit on someone's server ... even if might have an optional
   dependency on avahi in the standard Cockpit Fedora install.

 * Platforms like Atomic try very very very hard to get their bundled
   software stack down to a minimum. I would like the cockpit-bridge
   part of Cockpit to be usable anywhere. Even very lean environments.
   We're working hard to get there.

Having cockpit-bridge pull in an unused hard dependency on avahi-libs is
counter to both of the above goals. It seems that such a dependency
would need to be optional, which would make PCP be optional too.

The pcp-libs dependencies on cyrus-sasl and nss are less problematic,
despite the fact that they'd be unused by Cockpit, since those are
software more typically installed on a server.


cockpit-devel mailing list