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

[Hans-Christoph Steiner]

On Jun 17, 2008, at 8:36 AM, IOhannes m zmoelnig wrote:

> 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


In Debian, and probably other distros, /usr/lib is not for user- 
modified/user-added files, that's the problem with /usr/lib/pd.  So  
if we are going to follow the /usr/share policy, then we should  
follow related policies as well.

Then if it uses /usr/local/lib/pd, that would conflict with user- 
installed Pd versions.

.hc



------------------------------------------------------------------------ 
----

Looking at things from a more basic level, you can come up with a  
more direct solution... It may sound small in theory, but it in  
practice, it can change entire economies.     - Amy Smith