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

[IOhannes m zmoelnig]

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.  

who?
it's naturally easy, if you are already debian developer.
if you are not, it is rather hard (i know that the debcon is in ny, and
you will be a full fledged dd in 3 weeks or so; but not yet)
the experiences i made so far with mentors are rather unsatisfying in
this regard
that is: i haven't found a sponsor yet to upload either the new release
of puredata nor of gem.
with this in mind, the solution you suggest is rather illusory.

> Here's an example:
> 
> desiredata: /usr/lib/desiredata
> puredata: /usr/lib/pd
> pd-extended: /usr/lib/pd-extended
> libraries install path: /usr/lib/pd-externals
> 

an example for what?

here's another example:
 desiredata: /usr/lib/desiredata
 puredata: /usr/lib/pd
 pd-extended: /usr/lib/pd-extended
 libraries install path: /usr/lib/pd


mfgsdr
IOhannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20091202/e7b349b8/attachment.bin>