<p dir="ltr"><br>
On Jul 25, 2015 5:42 PM, "Jonathan Underwood" <<a href="mailto:jonathan.underwood@gmail.com">jonathan.underwood@gmail.com</a>> wrote:<br>
><br>
> On 26 July 2015 at 01:07, Jonathan Underwood<br>
> <<a href="mailto:jonathan.underwood@gmail.com">jonathan.underwood@gmail.com</a>> wrote:<br>
> [snip]<br>
> > As it goes, setuptools has ability to specify location of data files, see:<br>
> ><br>
> > <a href="http://peak.telecommunity.com/DevCenter/setuptools#including-data-files">http://peak.telecommunity.com/DevCenter/setuptools#including-data-files</a><br>
><br>
> Discussing this with upstream here:<br>
><br>
> <a href="https://github.com/mkdocs/mkdocs/issues/697">https://github.com/mkdocs/mkdocs/issues/697</a><br>
><br>
> it seems this whole issue is an unfortunate side-effect of mkdocs<br>
> reliance on entry points and that setuptools breaks the distutils<br>
> expectations of where data files are installed. The net result seems<br>
> to be that without re-engineering the whole python packaging stack<br>
> we're stuck with this situation. So, although it pains me greatly to<br>
> see such filesystem abuse, I think I am minded to say that this<br>
> shouldn't block mkdocs approval.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">-Toshio</p>