I&#39;ve been toying with the idea of a packaging system which would allow for file hierarchy independence. Today the Linux File Hierarchy is quite complex: several folders for binaries, several folders for *.conf files, several folders for *.so files etc. While this hierarchy may be good for a server environment, is far too complex for a&nbsp; desktop linux environment, as it isn&#39;t very intuitive. Another problem with the hierarchy is that different distributions use different paths, so packages used in one distro may not be good for another distro, thus the users have to look for repositories with packages for their own distro, and the maintainers have to waste quite a lot of time on building and testing those packages which have already been built by someone else for some other distro. The LSB project tries to solve this by standardizing the file hierarchy, but maybe there&#39;s a better way. <br>
<br>By letting the distro decide where to place files contained in the package we can solve the problem of maintaining multiple repositories of the same packages but for different distros, and also allow developers of different distros to create thir own file hierarchies - ones they think are better (for example a file hierarchy used by GoboLinux or a file hierarchy in the user&#39;s own language). I&#39;m not sure how feasible that is, though. One problem I can think of is when a program tries to open it&#39;s own config file or image file etc. using a path like &#39;../etc/program.conf&#39; or &#39;../share/program/image&#39;. So my question is: what other problems does anyone else see in implementing something like that?<br>