Bug 1300820 - sigul is installed in /usr/share/sigul/ instead of python sitelib
Summary: sigul is installed in /usr/share/sigul/ instead of python sitelib
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: sigul
Version: 23
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Patrick Uiterwijk
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-01-21 20:04 UTC by Adam Miller
Modified: 2016-09-02 16:25 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-09-02 16:25:43 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Adam Miller 2016-01-21 20:04:26 UTC
Description of problem:
It seems as though sigul should be installed into python sitelib as per Packaging Guidelines, is there a reason or particular motivation behind why it was not?

https://fedoraproject.org/wiki/Packaging:Python

$ rpm -ql sigul
/etc/logrotate.d/sigul
/etc/rc.d/init.d/sigul_bridge
/etc/rc.d/init.d/sigul_server
/etc/sigul
/etc/sigul/bridge.conf
/etc/sigul/client.conf
/etc/sigul/server.conf
/usr/bin/sigul
/usr/bin/sigul_setup_client
/usr/sbin/sigul_bridge
/usr/sbin/sigul_server
/usr/sbin/sigul_server_add_admin
/usr/sbin/sigul_server_create_db
/usr/share/doc/sigul
/usr/share/doc/sigul/AUTHORS
/usr/share/doc/sigul/COPYING
/usr/share/doc/sigul/NEWS
/usr/share/doc/sigul/README
/usr/share/man/man1/sigul.1.gz
/usr/share/man/man1/sigul_setup_client.1.gz
/usr/share/man/man8/sigul_bridge.8.gz
/usr/share/man/man8/sigul_server.8.gz
/usr/share/man/man8/sigul_server_add_admin.8.gz
/usr/share/man/man8/sigul_server_create_db.8.gz
/usr/share/sigul
/usr/share/sigul/bridge.py
/usr/share/sigul/bridge.pyc
/usr/share/sigul/bridge.pyo
/usr/share/sigul/client.py
/usr/share/sigul/client.pyc
/usr/share/sigul/client.pyo
/usr/share/sigul/double_tls.py
/usr/share/sigul/double_tls.pyc
/usr/share/sigul/double_tls.pyo
/usr/share/sigul/errors.py
/usr/share/sigul/errors.pyc
/usr/share/sigul/errors.pyo
/usr/share/sigul/server.py
/usr/share/sigul/server.pyc
/usr/share/sigul/server.pyo
/usr/share/sigul/server_add_admin.py
/usr/share/sigul/server_add_admin.pyc
/usr/share/sigul/server_add_admin.pyo
/usr/share/sigul/server_common.py
/usr/share/sigul/server_common.pyc
/usr/share/sigul/server_common.pyo
/usr/share/sigul/server_create_db.py
/usr/share/sigul/server_create_db.pyc
/usr/share/sigul/server_create_db.pyo
/usr/share/sigul/settings.py
/usr/share/sigul/settings.pyc
/usr/share/sigul/settings.pyo
/usr/share/sigul/utils.py
/usr/share/sigul/utils.pyc
/usr/share/sigul/utils.pyo
/var/lib/sigul
/var/lib/sigul/gnupg


Version-Release number of selected component (if applicable):
sigul-0.100-6.fc23.noarch

Comment 1 Colin Walters 2016-01-21 20:09:04 UTC
It's a common pattern for applications that happen to be written in Python, but aren't intended to actually be shared libaries.

Comment 2 Miloslav Trmač 2016-01-21 20:17:00 UTC
Thanks for your report.

sigul is not a library designed to be called from other applications, so AFAICT it makes no sense for it to be placed in a directory where other applications search for imports. There is not benefit to it, and there is a trivial cost of one more directory entry in that frequently-used directory, and a bit bigger cost of other people thinking that sigul might be expected to be used as a library.

These .py files are an internal architecture-independent aspect of sigul’s implementation which have nothing to do with Python’s modules in the default import path; /usr/share seems is the default place for internal architecture-independent files per FHS.

Compare e.g. /usr/share/{authconfig,hplip,rpmlint,system-config-printer,yum-cli}/virt-manager.

Can you please cite the exact part of the guidelines which requires placement in sitelib? I couldn't find it with a quick search for “sitelib”.

Comment 3 Fedora Admin XMLRPC Client 2016-08-09 14:55:25 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.


Note You need to log in before you can comment on or make changes to this bug.