# emonSD next steps

**URL:** <https://community.openenergymonitor.org/t/emonsd-next-steps/10426>\
**Category:** emonSD\
**Created:** [18 March 2019 15:12 UTC](https://community.openenergymonitor.org/t/emonsd-next-steps/10426 "2019-03-18T15:12:03Z")\
**Posts on this page:** 1\
**Showing post:** 106

<div class="post-metadata">

**Author:** ![djh](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/d/e36b37/32.png) [@djh](https://community.openenergymonitor.org/u/djh)\
**Post date:** [6 April 2019 09:31 UTC](https://community.openenergymonitor.org/t/emonsd-next-steps/10426/106 "2019-04-06T09:31:55Z")

</div>

> [@TrystanLea](#):
>
> Reading:  
> [Filesystem Hierarchy Standard](http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY)

FWIW, that’s an obsolete version of the spec - fifteen years old. The current version is [Filesystem Hierarchy Standard](http://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html)

/opt/package-name for code and move data directories to /var/opt/package-name for data after installation are reasonable places for external products to be placed. If a distro packages a product and releases it, then it will typically put it under /usr with data under /var/lib  
So the package should make sure it uses relative, and configurable paths to enable such changes. Ditto for its dependencies on other packages, which may live in different places on different systems. That also allows for multiple versions if the version number is in the path somewhere.

---

_[View the full topic](https://community.openenergymonitor.org/t/emonsd-next-steps/10426)._