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