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(a)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
> 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