[PD-dev] Re: Pd for Debian [was: Re: [PD] Pd-0.38.4-extended-RC6 release]

[Hans-Christoph Steiner]

On Dec 28, 2005, at 4:18 AM, Frank Barknecht wrote:

> Hallo,
> Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
>
>> The dependencies argument is a valid one, but that will be a lot of
>> work to setup and maintain, it seems to me.  Are you then going to  
>> have
>> to make pd-ogg, pd-mp3, pd-speex, pd-libsndfile, etc?
>
> I don't think it has to be such a black and white picture drawn just
> by technical demands. I'm actually in favour of a more use-oriented
> approach and I would draw the line between video/gfx and audio/midi.
> Pd itself is useless without basic audio or midi support. So the audio
> users would form the base user group. These people probably will have
> libsndfile or libogg installed anyways.
>
> Additionally there are gfx-oriented externals, which require audio
> stuff anyway, because of their dependency on Pd, but they also require
> stuff like video codecs, which is of no use on a purely audio system.
>
> I'm deliberately simplifiying here, of course, as e.g. Gridflow is
> much more than just a video external.
>
> A user who wants to have everything can just install every pd-related
> package, which could be made even easier in Debian by providing a
> dummy package, e.g. pd-complete, that is empty itself, but depends on
> all pd-related packages.
>
> So what I'm thinking of is just a handful of packages:
>
> * pd
> * pd-externals (including flext?)
> * pd-gfx (Gem and pdp, maybe Gridflow)
> * pd-doc (additional documentation, tutorials etc.)
> * pd-abstractions (this could also be merged with pd-externals)
> * And maybe language-specific packages like pd-python, pd-ruby,  
> pd-snd/-scheme.
>
> (I don't want to deinstall the whole Pd, just because there's a new
> python version coming...)
>
> IMO this kind of setup has advantages over the one-size-fits-all

> package both for users and maintainers.

Ok, I think I am convinced about the separate packages argument, since  
Pd is more of a programming language than an app.  But I think going  
back to the dependency argument, there should be a package of externals  
with only the very minimal dependencies (i.e. libc6, pd).  There are  
more and more people who only use Pd for video work, so I think the  
audio and video stuff should be treated the same

So here's my proposal for the layout:

pd (provided by puredata, desiredata, pd-devel, etc.)
pd-doc (this may be unclear, its more like built-in help than  
standalone docs)
pd-externals ("abstractions" and "externals" with no deps)
pd-audio (anything needing extra sound libs)
pd-video (virtual package for all video packages).
pd-gem
pd-pdp
pd-pidip
pd-gridflow
pd-pdp

pd-gem, pd-pdp, and pd-pidip already exist in some form, and having  
them separate would facillitate source building.  But its probably  
better to organize the packages in the most Debian way possible, rather  
than the Pd way since people who want to do things the Pd way can build  
directly from source.  I love Debian because everything is done the  
Debian way and makes my life much easier.

To fascillate this, it would probably make sense to add some special  
debian targets to "externals/Makefile".  Something like:

--------------
DEBIAN_EXTERNALS_TARGETS = buildsrc creb cxc cyclone ext13 freeverb hid  
iemabs iemlib iemmatrix loaders markex maxlib mjlib motex oscx pddp  
pmpd smlib toxy vbap zexy
debian_externals:
DEBIAN_AUDIO_TARGETS = pdogg unauthorized

debian_externals: $(DEBIAN_EXTERNALS_TARGETS)  $(DEBIAN_AUDIO_TARGETS)

debian_externals_install: $(patsubst %,  
%_install,$(DEBIAN_EXTERNALS_TARGETS)) \
$(patsubst %, %_install,$(DEBIAN_AUDIO_TARGETS))

debian_externals_clean: $(patsubst %,  
%_clean,$(DEBIAN_EXTERNALS_TARGETS)) \
$(patsubst %, %_clean,$(DEBIAN_AUDIO_TARGETS))

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

Then we should also remove "ogg*.c" from "externals/build/src" and make  
"pdogg" library, with its own build targets.

This packaging is a bit difficult to categorize since libs are  
currently organized by author rather than by functionality.  I think we  
should organize the pd packages by functionality, then over time, we  
can make libs along those lines also (like "math", "soundfile", etc.)

.hc
________________________________________________________________________ 
____

"Computer science is no more related to the computer than astronomy is  
related to the telescope."
                                                           -Edsger  
Dykstra