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

Frank Barknecht fbar at footils.org
Wed Dec 28 08:20:09 CET 2005


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".

> >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. ;)

> 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.)

Ciao
-- 
 Frank Barknecht                 _ ______footils.org_ __goto10.org__




More information about the Pd-dev mailing list