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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
