[Bug 491497] Review Request: dmapd - A server that provides DAAP and DPAP shares

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=491497

--- Comment #21 from Christian Krause <chkr at plauener.de> 2010-01-28 17:49:22 EST ---
(In reply to comment #20)
> The rpmlint message is clearly a false positive. I'm not claiming that my code
> is perfect, but I do think it is bad practice to modify it because rpmlint made
> an unjustified complaint. To be honest, the right answer would probably be to
> replace the use of "dmapd" with $prog in all but the prog= declaration.

I agree that it may be arguable whether this warning is important or not.
However, the fix I've suggested in comment #17 would be still correct. It would
not compromise the readability of the script, but it would make the warning
vanish. Having as less warnings as possible will help later during maintenance
or auditing. (There are also other warnings of rpmlint like the usage of spaces
vs. tabs in the spec file which may be also debatable but which should be still
honored.)

Please do this little fix.

> I would like some more official feedback regarding the /var/db/dmapd issue. As
> I stated, I am going for ease of install. There is a precedent for this
> technique (httpd's /var/www comes to mind). Also, the choice of /var is
> consistent with the FHS. There is precedent for db, but I am not wed to it
> (i.e., one could argue /var/lib is better, but the FHS is a bit vague on the
> intent behind this directory). I'd like to find a clear Fedora policy on 1)
> creating a data directory so that a pre-configured server may be installed 2)
> /var/db vs. /var/lib, etc.    

The feedback I got from fedora-packaging indicates, that /var/db/dmapd should
not be used. I'd still suggest to not package an directory for the
music/video/photo files at all and explicitly require that the user should
configure it.

I also believe that we should make it easy for the user, but your proposed
solution requires also a standard user to know how he/she can copy files into
the directory solely owned by a different user (dmap in this case).

The easiest way would be to check whether the user has configured at least one
directory in /etc/sysconfig/dmapd and abort the init script otherwise.


I was going to do a final functionality test, but unfortunately dmapd doesn't
start at all:

:~# /etc/init.d/dmapd start
Starting dmapd: /usr/lib/dmapd/0.0.18/modules/libav-meta-reader-gst.so: cannot
open shared object file: No such file or directory

** ERROR **: Error opening
/usr/lib/dmapd/0.0.18/modules/libav-meta-reader-gst.so
aborting...
/bin/bash: line 1: 19791 Aborted                 /usr/sbin/dmapd --user dmapd
-m /var/db/dmapd/Music -m /var/db/dmapd/Movies -p /var/db/dmapd/Pictures
                                                           [FAILED]

When you provide a new package, please give it always a quick smoke test. ;-)

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.