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

Hans-Christoph Steiner hans at eds.org
Wed Dec 28 11:27:17 CET 2005


On Dec 27, 2005, at 11:20 PM, Frank Barknecht wrote:

> Hallo,
> Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
>
>> On Dec 27, 2005, at 1:57 AM, Frank Barknecht wrote:
>>> So I do this:
>>> $ make externals prefix=/usr DESTDIR=/home/fbar/tmp/pd-pack
> ...
>>> It bails out with this:
>>>
>>> cd
> ...
>
>> That's very strange.   I can't reproduce this on Debian, Mac OS X, or
>> Windows.  Its trying to compile [hid] files into the [ENV] object.
>> Have you don't a "cvs up -Pd" on "externals" and "packages"?   Are
>> there any files in your "externals/build/src" which are not from CVS?
>
> I am doing all this with superfresh checkouts actually, using the
> developer-checkout script from "scripts".

I found the problem and fixed it.  It was my fault, sorry about that.   
I am going crazy keeping track of files on three different computers  
(Mac OS X, Debian, and Windows).  "cvs up externals/Makefile" and  
please try again.


>>> And actually I want to build externals without Gem, as Gem also has
>>> nice Pd packages and may be easier built from its own CVS. I would at
>>> least vote for making Gem, PDP/Pidip and Gridflow their own targets
>>> inside the makefile, like "make gem(_install) gridflow(_install)
>>> pdp(_install)"
>>
>> cd externals && make pdp_install
>> cd externals && make pidip_install
>
> Okay, this looks like a good idea.
>
>> I know nothing about building GridFlow, and Gem can be compiled by:
>> cd packages && make gem_install
>
> Or not compiled. ;)

Oops, sorry, I forgot its not included yet since I haven't worked on  
the autotools building of Gem yet.

>> Personally, I think that the Debian packages should reflect the other
>> Pd-extended builds and just be one package.  I could see separating  
>> out
>> the Pd core, so that you could use different versions with the same
>> pd-extended externals, docs, etc. but that might cause problems since
>> some externals might only work properly with the version of Pd that
>> they were compiled against.
>>
>> I just don't see any advantage to having all of this stuff separated
>> into separate packages.  For example, Gem is useless without Pd, and  
>> if
>> its not being used it does no harm, it just takes up disk space.
>
> It takes up much more because of all the dependencies it has. And
> dependencies are not only something which takes up disk space, they
> are something which can and will break on upgrades.
>
> If someone is not interested in the video side of Pd at all or if
> someone wants to run Pd on an X-less webserver, then there would be no
> need to install Gem and all its dependencies. Without Gem and pdp, an
> externals package's dependencies would be supersmall, but including
> Gem and pdp you need a really huge list of packages to install for two
> externals, that are totally useless to maybe half of Pd's usersbase
> (just a guess for the sake of the argument).
>
> And I'm not even mentioning build-dependencies yet, which should also
> be taken into account at least on Debian and probably Gentoo.
>
> That's why I would prefer that Gem and pdp go into their own packages
> (and that pd-extended reflects the Debian builds and just be several
> packages ;) and users can make their own choice. (And they chose
> Firefox and Thunderbird over Mozilla.)

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?

Audacity is a good example, its a similar program.  The audacity  
package has a long list of deps on top of the minimum: libflac++5,  
libflac7, libid3tag, libmad0, libogg0, libsndfile1, libunwind7,  
libvorbis0a, libvorbisen2, libvorbisfile3.   Ardour has an even longer  
list: http://packages.debian.org/unstable/sound/ardour-gtk, and ffmpeg  
has a decent list too:  
http://packages.debian.org/unstable/graphics/ffmpeg

I think that Pd is much closer to Ardour/Audacity/ffmpeg than Mozilla,  
especially when you consider that Firefox and Thunderbird are  
standalone apps, while none of the Pd sub-packages will do anything  
without Pd.

But I am probably not going to do the work, so its just my opinion.

.hc


________________________________________________________________________ 
____

News is what people want to keep hidden and everything else is  
publicity.
                                                                          
                      - Bill Moyers





More information about the Pd-dev mailing list