Hi,
During the review of mkdocs[1], which is a python package for generating static webpages, I (as reviewer) noticed that it installs a lot of themes (javascript, fonts and the like) under /usr/lib/python3/site-packages/mkdocs/themes.
My feeling is that this static architecture independent data should really be installed under /usr/share/mkdocs to comply with the FHS[2]. But the packager (quite reasonably) points out that other packages such as sphinx install templates and themes under /usr/lib/python3/site-packages.
So, the question is: is it acceptable for this package to install arch independent themes (i.e. non-python code) under /usr/lib/python3/site-packages ?
TIA, Jonathan
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1230963 [2] http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE26
On 25 July 2015 at 01:37, Jonathan Underwood jonathan.underwood@gmail.com wrote:
Hi,
During the review of mkdocs[1], which is a python package for generating static webpages, I (as reviewer) noticed that it installs a lot of themes (javascript, fonts and the like) under /usr/lib/python3/site-packages/mkdocs/themes.
My feeling is that this static architecture independent data should really be installed under /usr/share/mkdocs to comply with the FHS[2]. But the packager (quite reasonably) points out that other packages such as sphinx install templates and themes under /usr/lib/python3/site-packages.
So, the question is: is it acceptable for this package to install arch independent themes (i.e. non-python code) under /usr/lib/python3/site-packages ?
As an extra data point, it seems Debian places sphinx themes under /usr/share:
On Sat, Jul 25, 2015 at 10:59 PM, Jonathan Underwood jonathan.underwood@gmail.com wrote:
As an extra data point, it seems Debian places sphinx themes under /usr/share:
You can't rely on Debian always in Fedora ;)
Will the new package with data moved to /usr/share work? Have you tested? My opinion is to create a noarch for these static files and let package depend on it. However you said there are also fonts so it's tricky now.
On 25 July 2015 at 16:47, Christopher Meng cickumqt@gmail.com wrote:
Will the new package with data moved to /usr/share work? Have you tested?
The package could be patched to work.
My opinion is to create a noarch for these static files and let package depend on it.
Splitting out the files into a sub-package is orthogonal to the original question (and also not needed IMO).
However you said there are also fonts so it's tricky now.
The fonts have been unbundled and replaced with symlinks, as detailed in the review ticket.
-- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
I am the packager of mkdocs.
During the review of mkdocs[1], which is a python package for
generating static webpages, I (as reviewer) noticed that it installs a lot of themes (javascript, fonts and the like) under /usr/lib/python3/site-packages/mkdocs/themes.
python-sphinx Ipython python-werkzeug and python-django also put .js files under %{python2_sitelib} or %{python3_sitelib} and this only a simple find in my system, so it is safe to think than many python packages put arch indepent data under %{python2_sitelib} and %{python3_sitelib} , removing bundled fonts and replaced with symlinks.
So all those packages must be fixed or mkdocs can put this data under %{python3_sitelib}
My feeling is that this static architecture independent data should really be installed under /usr/share/mkdocs to comply with the FHS[2]. But the packager (quite reasonably) points out that other packages such as sphinx install templates and themes under /usr/lib/python3/site-packages.
For me the data under %{python3_sitelib} is arch indepent, Python code that is not arch indepent is under %{python3_sitearch} so the arch independent argument is not good enough to move these files.
See: https://en.opensuse.org/openSUSE:Packaging_Python#System_Architecture
So, the question is: is it acceptable for this package to install arch
independent themes (i.e. non-python code) under /usr/lib/python3/site-packages ?
For me put these files under /usr/lib/python3/site-packages is not a bad packaging.
On 26 July 2015 at 00:13, William Moreno williamjmorenor@gmail.com wrote: [snip]
For me the data under %{python3_sitelib} is arch indepent, Python code that is not arch indepent is under %{python3_sitearch} so the arch independent argument is not good enough to move these files.
You're misunderstanding my point. It's not the fact that it is arch independent that is significant. This isn't about %{python3_sitelib} vs. %{python3_sitearch} (both would be the wrong place for static data). It's the fact that it is *static data* (and arch independent), and not python library code. The FHS is very clear that static data which is arch independent should go under /usr/share.
See: https://en.opensuse.org/openSUSE:Packaging_Python#System_Architecture
There's nothing in that document germane to the issue as far as i can see.
As it goes, setuptools has ability to specify location of data files, see:
http://peak.telecommunity.com/DevCenter/setuptools#including-data-files
So, the question is: is it acceptable for this package to install arch independent themes (i.e. non-python code) under /usr/lib/python3/site-packages ?
For me put these files under /usr/lib/python3/site-packages is not a bad packaging.
But your reasoning is simply "because other packages do it". I am afraid I don't feel that is a valid argument.
Jonathan.
On 26 July 2015 at 01:07, Jonathan Underwood jonathan.underwood@gmail.com wrote: [snip]
As it goes, setuptools has ability to specify location of data files, see:
http://peak.telecommunity.com/DevCenter/setuptools#including-data-files
Discussing this with upstream here:
https://github.com/mkdocs/mkdocs/issues/697
it seems this whole issue is an unfortunate side-effect of mkdocs reliance on entry points and that setuptools breaks the distutils expectations of where data files are installed. The net result seems to be that without re-engineering the whole python packaging stack we're stuck with this situation. So, although it pains me greatly to see such filesystem abuse, I think I am minded to say that this shouldn't block mkdocs approval.
On Jul 25, 2015 5:42 PM, "Jonathan Underwood" jonathan.underwood@gmail.com wrote:
On 26 July 2015 at 01:07, Jonathan Underwood jonathan.underwood@gmail.com wrote: [snip]
As it goes, setuptools has ability to specify location of data files,
see:
http://peak.telecommunity.com/DevCenter/setuptools#including-data-files
Discussing this with upstream here:
https://github.com/mkdocs/mkdocs/issues/697
it seems this whole issue is an unfortunate side-effect of mkdocs reliance on entry points and that setuptools breaks the distutils expectations of where data files are installed. The net result seems to be that without re-engineering the whole python packaging stack we're stuck with this situation. So, although it pains me greatly to see such filesystem abuse, I think I am minded to say that this shouldn't block mkdocs approval.
I don't believe I've blocked packages on this either, however it is relatively simple to comply with the fhs and support the packages' notions of file placement using symlinks.
There are some cases where I always moved the files and patched the code to find it on the correct place: documentation, locales, man pages, fonts, and such. Those are things that have a specific type and specific place under the fhs and fedora so it would be wrong to let those specific classes of file go unmoved wherever upstream puts them.
-Toshio
packaging@lists.fedoraproject.org