[PD-dev] adding standard install paths to the 'puredata' package

[Hans-Christoph Steiner]

On Dec 2, 2009, at 4:11 AM, Frank Barknecht wrote:

> Hallo,
> IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
>
>> Hans-Christoph Steiner wrote:
>>>
>>> The compelling reason is that 'pd' means multiple packages  
>>> 'puredata',
>>> 'pd-extended', and perhaps others.  Where is the harm in changing  
>>> this?
>>
>> but there are so many trivial patches in the world that won't do no  
>> harm
>> to anybody. this is not a reason to apply them "just so".
>>
>> i understand that /u/l/puredata seems to be more natural than /u/l/ 
>> pd.
>> however, so far _this_ hasn't caused any problems i know of yet.
>> so why change it?
>> if it does cause problem and changing it to /usr/lib/puredata would  
>> fix
>> them, then i don't see a reason not to change it.
>>
>>> Its a trivial patch, its not a directory that people should be ever
>>> changing since its managed by the packages.  If it causes  
>>> problems, we
>>> can change it back.
>
> Wow, that's a cute attitude for a maintainer!

> Renaming "/u/l/pd" to "/u/l/puredata" is a solution in search of a  
> problem.  Pd
> upstream uses /usr/(local/)lib/pd for ages. All documentation is  
> written with
> this in mind, many Makefiles use it as default. The only reason why  
> someone may
> consider to use /usr/(local/)lib/puredata instead is that the Debian  
> package is
> called "puredata". But this is a very specific peculiarity of this  
> particular
> distribution.

An example of a problem this is trying to solve: if 'puredata' is at  
version 0.42.5 and 'pdextended' and 'desiredata' are not at 0.42.5  
yet, then there would be an incompatibility in the 'extra' objects  
that are in the /usr/lib/pd/extra.  Another possible approach would be  
making a 'pd-extra' package that has that stuff in it.  That would  
have to be packaged so that its loadable as a distinct library to make  
it work, as far as I can see.

> Miller's source archive is called "pd", the autobuilds use "pd"
> or for Pd-extended "Pd-<version>-extended" which is a completely  
> illegal
> package name as far as Debian's policy is concerned btw.

Yes, that's just old crufty scripts, the official releases are all  
done right.  They are in the SVN in scripts/auto-build for anyone who  
wants to fix them.

> If you want to support and package the various forks of Pd, then the  
> only thing
> you need to do is make a meta package "pd" and let all forks provide  
> "pd", and
> that's already done and in fact is the reason for Debian's pd  
> package carrying
> the name "puredata"!  It's no problem to have them all use a shared  
> directory
> for extensions as far as Debian and the filesystem is concerned. I  
> mentioned
> the vim packages as an example. If you want fork-specific data, you  
> can always
> add special directories in these packages, like /usr/lib/puredata- 
> extended


You highlight the core of the issue: there is a common understanding  
of what /usr/lib/pd means in the Debian packaging.  That meaning was  
defined by a single 'pd' package.  There is now 'puredata' and 'pd- 
extended' packages and a 'desiredata' one would nice, so we can all  
benefit from a plan to have library packages that work for all. But  
that means the definition of /usr/lib/pd has to be changed.  We  
discussed these this at the last PdCon, and there was agreement on the  
fact that the three directories are needed.  So then we have three  
directories that overlap the meaning of the original /usr/lib/pd:

1. a /usr/lib directory for objects that work for everything that  
provides 'pd'
2. a /usr/lib directory for objects that work only for 'puredata'
3. a /usr/lib directory for objects that work only for 'pd-extended'

I am ok with keeping /usr/lib/pd as the first directory since it  
matches the virtual package 'pd'.  (Previously we'd decided on /usr/ 
lib/pd-externals as the name for the first directory).    In terms of  
the packaged libraries, using /usr/lib/pd for the first directory  
means the existing ones don't have to change unless they are  
incompatible with Pd-extended/DesireData.  But that means changing the  
'puredata' package to use /usr/lib/puredata for the stuff that comes  
in pd/extra (i.e. bonk~, etc).

I tried to start encapsulating these discussions here, please add  
things:
http://puredata.info/dev/DebianPackagingStructure

.hc



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

You can't steal a gift. Bird gave the world his music, and if you can  
hear it, you can have it. - Dizzy Gillespie