Hans-Christoph Steiner wrote:

On Feb 1, 2010, at 3:38 AM, IOhannes m zmoelnig wrote:

...

Hans-Christoph Steiner wrote:

...

Hey all,

Just finished a weekend long Debian Bug Squashing Party here in NYC. I discussed with a few Debian Developers how best to fit Pd's files into Debian Policy. This is what we came up with. Let me know what you guys think, and whether there are other things to add.

• While .pd files are plain text, they are really like scripts most

of all, and should be treated that way. That means they should go into /usr/lib/pd rather than the data dir /usr/share/pd *help patches are just Pd patches, which are just scripts, so it is also ok for them to be included in /usr/lib/pd.

• Help patches are not really useful to read outside of Pd so the

help patches should not go into `/usr/share/doc'

• HTML, PDFs?, .txt, and READMEs? should go into /usr/share/doc like

any other package

i guess this pretty much expresses the current state of the puredata package, no?

one issue that seems to have been untouched: what about "examples"? e.g. Gem has a largish collection of example Pd patches, which traditionally go into /usr/share/doc (and are then symlinked to /usr/lib/pd to make Pd find it) i still very much like this, and for me it seems like it is in accordance to what other packages do: about 10% of the packages installed on my machine have a /usr/share/doc/<package>/examples/ directory, which is often filled with rcfiles and/or programming examples. e.g. loads of python modules will put example code into this directory.

FYI: was mostly discussing this stuff in the context of the libdir/dirlib approach of having all the files related to a library in a self-contained folder. I believe this is a good approach for Pd, so I was thinking about how it can fit into Debian Policy, which is going to be helpful for UNIX distros in general.

i see. thanks for clarification.

So I am thinking now that we should package libraries as libdirs in /usr/lib/pd, then symlink things to other appropriate places. Then in the Pd implementation, we can count on libdirs always being there, but from the Debian side, everything will be accessible from the right places.

what do you mean by the "other appropriate places"? things like /usr/lib/pd-extended/ (which is probably a bad idea), or like /usr/share/pd (which doesn't make much sense imho, as because users probably won't insist on the peculiarities of pd-patches being platform independent and therefore meant to be in /usr/share; and Pd will look for them in /usr/lib/pd anyhow)

i'm really just trying to find out whether this statement is only to protect the agreed on layout against nit-pickers or whether yuo have any real use-cases in mind.

While I think that help patches don't belong in /usr/share/doc/<package>, I think it could make sense to put examples

agreed, if we mean "reference patches" when we say "help patches": files that are "primarily" (whatever that means :-)) used as code for the built-in help system of Pd (rather than as a manual for the user to study). obviously help/reference patches are kind of both, but for me the reason why they are not in /usr/share/doc is their useage as code-to-be-found-and-interpreted.

into /usr/share/pd or maybe /usr/share/doc/pd. AFAIK, the stuff in /usr/share/doc/ is meant to be readable plain text, like via less, a web browser, text editor, or something like that. Pd patches are not, so it might not make much sense to put them in /usr/share/<package> or /usr/share/doc/<package>. It doesn't really hurt either, so symlinking stuff to /usr/share/doc/<package> seems workable.

äh: please explain the difference between /usr/share/doc/pd and /usr/share/doc/<pkg>, with regard to "readable text".

looking through my /usr/share/doc i find quite some xml files, which i think are about as plain text and as human readable as Pd patches. (apart from xml and all the "media data", pdfs and postscripts, i find also certificates, rtfs, tex aux, diskimage, compiled(!) java and what not files in /usr/share/doc/<pkg>/). i have to admit that i haven't checked whether the packages containing these files have any pending lintian problems.

personally, if i looked for documentation on e.g. ggee, i would first go into /usr/share/doc/ggee and expect the documentation to be there. now symlinking kind of helps here, butn i fear this might get us into symlink hell for no good reasons. to avoid conflicts, it would have to be like /usr/share/doc/pd/examples/<pkg>/... which is not much better than /usr/share/doc/<pkg>/, especially since most packagesare prefixed "pd-" anyhow.

to conclude: what is the reason for putting things into /usr/share/doc/pd rather than /usr/share/doc/<pkg>?

fmngasdr IOhannes