[PD-dev] packaging the pddp docs

Hans-Christoph Steiner hans at at.or.at
Tue Jun 28 18:33:21 CEST 2011


On Jun 28, 2011, at 11:43 AM, Jonathan Wilkes wrote:

>
>
> --- On Tue, 6/28/11, Hans-Christoph Steiner <hans at at.or.at> wrote:
>
>> From: Hans-Christoph Steiner <hans at at.or.at>
>> Subject: Re: [PD-dev] packaging the pddp docs
>> To: "Jonathan Wilkes" <jancsika at yahoo.com>
>> Cc: pd-dev at iem.at
>> Date: Tuesday, June 28, 2011, 5:11 PM
>>
>> On Jun 28, 2011, at 12:55 AM, Jonathan Wilkes wrote:
>>
>>>
>>>
>>> --- On Tue, 6/28/11, Hans-Christoph Steiner <hans at at.or.at>
>> wrote:
>>>
>>>> From: Hans-Christoph Steiner <hans at at.or.at>
>>>> Subject: Re: [PD-dev] packaging the pddp docs
>>>> To: "Jonathan Wilkes" <jancsika at yahoo.com>
>>>> Cc: pd-dev at iem.at
>>>> Date: Tuesday, June 28, 2011, 6:27 AM
>>>>
>>>> On Jun 27, 2011, at 6:45 PM, Jonathan Wilkes
>> wrote:
>>>>
>>>>>
>>>>>
>>>>> --- On Mon, 6/27/11, Hans-Christoph Steiner
>> <hans at at.or.at>
>>>> wrote:
>>>>>
>>>>>> From: Hans-Christoph Steiner <hans at at.or.at>
>>>>>> Subject: [PD-dev] packaging the pddp docs
>>>>>> To: pd-dev at iem.at
>>>>>> Date: Monday, June 27, 2011, 9:21 PM
>>>>>>
>>>>>> Now that the core Pd docs (i.e.
>> /usr/lib/pd/doc/*)
>>>> are
>>>>>> split out into a
>>>>>> separate Debian package, I think it could
>> make
>>>> sense to
>>>>>> package the PDDP
>>>>>> docs in a kind of mirror or replacement
>> package.
>>>>>> Something like
>>>>>> pddp-doc.  Jonathan, in particular, I
>> was
>>>> thinking
>>>>>> that since you have
>>>>>> wanted to work on all the patches there,
>> we could
>>>> set it up
>>>>>> so the
>>>>>> pddp-doc package mirrors the whole
>>>> /usr/lib/pd/doc*
>>>>>> directory and patch
>>>>>> structure, have this in SVN, git, or
>> whatever
>>>>>> somewhere.  Then people
>>>>>> could choose the pddp-doc package if they
>> so
>>>> choose.
>>>>>
>>>>> The PDDP docs I did are all for vanilla
>> objects
>>>> (exceptions are
>>>>> expr family, and the other "vanilla"
>> extras).  If
>>>> a new user clicks
>>>>> "Help" on a vanilla object, it should show the
>> revised
>>>> PDDP help
>>>>> patch by default.
>>>>>
>>>>> So instead of what you propose, please make
>> something
>>>> like a
>>>>> legacy-vanilla-help package.  That way,
>> if
>>>> someone really prefers
>>>>> the old docs, they can still find them, and we
>> won't
>>>> waste new users' time
>>>>> by forcing them to use outdated and
>> unmaintained docs
>>>> (until they figure
>>>>> out they're supposed to download a separate
>> package
>>>> for the current
>>>>> vanilla help patches, which nobody has to do
>> for any
>>>> of the external
>>>>> packages).
>>>>>
>>>>> -Jonathan
>>>>
>>>>
>>>> I agree that the PDDP docs are much better, that's
>> why I
>>>> want to get them out there more.  Part of
>> packaging is
>>>> representing the upstream as it is and letting the
>> user
>>>> decide.  So I think it makes sense to keep
>> puredata-doc
>>>> as what's included in the official tarball.
>> As for
>>>> Pd-extended, I think it should still use the PDDP
>> docs, so
>>>> like you say, showing the PDDP docs by default.
>>>
>>> Ok.
>>
>>
>> So we just need a plan of attack.  If you can lead up
>> this project, I
>> will help as much as I can.  Do you want to include
>> the whole docs
>> tree in the doc/pddp SVN?  Or something else?  It
>> seems to me the
>> easiest would be to start a separate repository for them,
>> like on
>> SourceForge, pddp is available: http://sourceforge.net/projects/pddp
>>
>> Or we could reorganize doc/pddp in the pure-data SVN.
>>
>> .hc
>
> Since Pd-extended and Pd-l2ork already use the PDDP docs, the only  
> thing
> we're talking about here is providing PDDP docs for people who use
> vanilla, and that's a simple commit.  So I don't see why I have to  
> head up
> some new project and learn Debian packaging in order to meander  
> toward (or
> around) that goal.

Its not a new project. I see it as a better representation of what's  
currently happening.  You are doing great work with the PDDP docs, I  
think we can make the structure of that project work better for you.   
Having it as a distinct entity means you are less encumbered by others  
when making decisions about what should happen with PDDP.  That  
distinct entity can be either a folder in the pure-data SVN, a  
separate SourceForge project, or whatever we think is easiest.  I  
think one of the first two options would work well.

I'm happy to do all of the Debian packaging, that part would be easy  
for me.

> The only problem is with pddplink and helplink dependencies, which  
> should
> just be included in vanilla as internal objects.  Is there a good  
> reason
> why they aren't?

That's something you'd have to take up with Miller, only he makes the  
call there.  Honestly, I think we're better off keeping things as  
distinct libraries.  Miller has limited time to spend on Pd, so the  
more stuff that's in Pd, the thinner his time is spread.  pd-pddp is  
in Debian/Ubuntu/Mint etc.  For someone who knows Fedora/RPM  
packaging, it would be really easy to package it.  Then PDDP is  
included in Pd-extended already. So that means for the vast majority  
of users, pddplink and helplink are already part of the standard  
install.

> Maybe my time would be better spent making a "gui" plugin that just  
> grabs
> all the stuff that should be core pd but isn't and installs it:
> revised/maintained docs, [initbang], [closebang], [pddplink],  
> [helplink],
> $@, etc.

That's done, that's called Pd-extended ;)

.hc

>
> -Jonathan
>
>
>
>>
>> ----------------------------------------------------------------------------
>>
>> Using ReBirth is like trying to play an 808 with a long
>> stick.    -
>> David Zicarelli
>>
>>
>>



----------------------------------------------------------------------------

The arc of history bends towards justice.     - Dr. Martin Luther  
King, Jr.





More information about the Pd-dev mailing list