On Jun 28, 2011, at 11:43 AM, Jonathan Wilkes wrote:
--- On Tue, 6/28/11, Hans-Christoph Steiner <h...@at.or.at> wrote:
From: Hans-Christoph Steiner <h...@at.or.at>
Subject: Re: [PD-dev] packaging the pddp docs
To: "Jonathan Wilkes" <jancs...@yahoo.com>
Cc: pd-dev@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 <h...@at.or.at>
wrote:
From: Hans-Christoph Steiner <h...@at.or.at>
Subject: Re: [PD-dev] packaging the pddp docs
To: "Jonathan Wilkes" <jancs...@yahoo.com>
Cc: pd-dev@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
<h...@at.or.at>
wrote:
From: Hans-Christoph Steiner <h...@at.or.at>
Subject: [PD-dev] packaging the pddp docs
To: pd-dev@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.
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
