Hans-Christoph Steiner wrote: > > On Jun 16, 2008, at 3:46 PM, IOhannes m zmoelnig wrote: > >> Hans-Christoph Steiner wrote: >>> With this release of Pd-extended, all platforms have default >>> locations for user-installed externals, helpfiles, etc. I just had >>> a thought, perhaps ~/.pd would be a better directory than ~/pd. >>> Any thoughts on that? >> >> i would rather have the configuration file(s) move into ~/.pd/ >> this way it is easy to add conffiles for other Pd-related stuff >> without cluttering the ~ even more. >> >> >>> Here's how it is now: >>> GNU/Linux: /usr/share/pd and ~/pd >> >> ouch! >> according to the Filesystem Hierarchy Standard >> (http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA), >> >> this directory is reserved for "Architecture-independent data". >> traditional ("C") externals do not exactly fall into this category. > > Any suggestions for a better location? I know /usr/share/pd is not > ideal, but I couldn't think of anything better.
hmm, what is wrong with /usr/lib/pd ? neither /usr/share nor /usr/lib nor the entire /usr are free for the _user_ (despite the name); /usr contains "shareable, read-only data" (FHS); this is usually interpreted as being under the sole control of the package-manager (if such a thing exists), and is in any case _system wide_. so, it would be ok if abstractions, python-externals and other platform-independent objects would go into /usr/share/pd whereas compiled (that is: platform dependent) objects (aka: C-externals) must go into /usr/lib/pd for the sake of simplicity i would say it doesn't make so much sense, i would therefore suggest to just stay with /usr/lib/pd (it would make sense if Pd-extended was split into several packages, some of them being plaftorm-dependent (containing binaries) and other platform-independent) fmgasd,.r IOhannes _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
