[PD-dev] Debian Policy for Pd packages

[IOhannes m zmoelnig]

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

-------------- 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/20100202/bd331914/attachment.bin>