Bug 1039291

This is a little too terse and vague for me to grok.

What is it that you think is the problem — that rsyslog packages are now required? Why is that a problem?

Sorry, I just converted to journald (and removed rsyslog).

My recollection (perhaps faulty) was that installing rsyslog will install/setup systemd units for it as well, and will "re-enable" rsyslog.

Yup, I updated glusterfs (which installed rsyslog), and now I have rsyslog enabled:

[root@tlondon ~]# systemctl status rsyslog.service
rsyslog.service - System Logging Service
   Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled)
   Active: active (running) since Mon 2013-12-09 06:49:50 PST; 6min ago
 Main PID: 651 (rsyslogd)
   CGroup: /system.slice/rsyslog.service
           └─651 /sbin/rsyslogd -n

Dec 09 06:49:49 tlondon.localhost.org systemd[1]: Starting System Logging Ser...
Dec 09 06:49:50 tlondon.localhost.org systemd[1]: Started System Logging Serv...
Hint: Some lines were ellipsized, use -l to show in full.
[root@tlondon ~]# 

Is that what is expected? I had it disabled/removed prior to this....

Yes, we are using rsyslog.

I'm inclined to think this is Not-A-Bug and close it. Bala, what do you think?

Yes.  We use rsyslog ATM.  Closing as NOTABUG

The strict requirement in -libs is completely bogus. You ship an _example_ rsyslog config in the main glusterfs package that wouldn't even be enabled unless the admin does it.

-libs is used throughout the stack with the majority of users not even remotely close to having a glusterfs setup.

On a related note, the -api requirements also seem suspect.

The subpackage is a runtime thing yet it requires glusterfs-devel.

The Requires = %{name}  probably should be %{name}-libs

The python part could be split up from the main api library to avoid bringing up python where its not needed

(In reply to Yanko Kaneti from comment #7)
> On a related note, the -api requirements also seem suspect.
> 
> The subpackage is a runtime thing yet it requires glusterfs-devel.

This has been addressed with Bug 1016938.

> The python part could be split up from the main api library to avoid
> bringing up python where its not needed

That is planned for the future (3.6 release), the Python gfapi.py bindings are moving to their own package (and project):
- https://github.com/gluster/libgfapi-python

I'll close this bug report now. Please open separate bugs for separate issues.

Sorry but I'll reopen this again because comment 8 doesn't actually address the main issue in this bug of glusterfs-libs hard dependency on rsyslog-mmjsonparse, hence rsyslog.
Maybe DEFERRED means something I don't understand.

Why this (indirect rsyslog dependency) is a bug:

https://fedoraproject.org/wiki/Changes/NoDefaultSyslog states that a default installation should not contain rsyslog and glusterfs is installed by default. Thus having glusterfs depend on rsyslog is unwanted beaviour.

Kaleb, I don't know what this GlusterFS product is.
What the reporter and I care about is the spurious hard dependency on rsyslog in  glusterfs-libs  in Fedora.
I am cloning bug back to Fedora.

$ rpm -q --requires -p glusterfs-libs-3.5.3-1.fc21.i686.rpm
/bin/sh
/bin/sh
libc.so.6
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.1.1)
libc.so.6(GLIBC_2.1.3)
libc.so.6(GLIBC_2.11)
libc.so.6(GLIBC_2.17)
libc.so.6(GLIBC_2.2)
libc.so.6(GLIBC_2.2.3)
libc.so.6(GLIBC_2.3)
libc.so.6(GLIBC_2.3.2)
libc.so.6(GLIBC_2.3.4)
libc.so.6(GLIBC_2.4)
libc.so.6(GLIBC_2.8)
libcrypto.so.10
libcrypto.so.10(libcrypto.so.10)
libdl.so.2
libdl.so.2(GLIBC_2.0)
libdl.so.2(GLIBC_2.1)
libgfrpc.so.0
libglusterfs.so.0
libm.so.6
libpthread.so.0
libpthread.so.0(GLIBC_2.0)
libpthread.so.0(GLIBC_2.1)
libpthread.so.0(GLIBC_2.2)
libpthread.so.0(GLIBC_2.3.2)
libpython2.7.so.1.0
libutil.so.1
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
rtld(GNU_HASH)