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. 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.
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
Ciao