[PD] /usr/share/pd (was Re: ~/pd or ~/.pd for user's externals directory)

[IOhannes m zmoelnig]

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