[PD-dev] adding standard install paths to the 'puredata' package

Hans-Christoph Steiner hans at at.or.at
Sat Dec 5 16:30:23 CET 2009


On Dec 5, 2009, at 7:51 AM, Frank Barknecht wrote:

> Hallo,
> Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
>
>> The problem is versioning.  One of the goals of Pd-extended is to be
>> compatible with the same version of Pd-vanilla, i.e. Pd-extended  
>> 0.40.3
>> can run anything that Pd-vanilla 0.40.3 can.  I imagine that  
>> desiredata
>> has a similar goal, but maybe not.  The objects in 'extra' are part  
>> of
>> what Pd-vanilla 0.40.3 provides.
>
> Okay, now here's an issue: I agree that the objects in "extra" are  
> something,
> that "pd" should provide. But if the packages "pdextended" and  
> "desiredata"
> provide "pd" they also have to provide, say, expr.pd_linux, even if  
> "puredata"
> is not installed. This gets even hairier with things like helpfiles:  
> a package
> that provides "pd" should include and provide route-help.pd, of  
> which we have a
> different one in PDDP which maybe is part of "pdextended.deb" (or  
> maybe isn't).
>
>> So if the objects in extra come with the 'puredata' package and are  
>> put
>> into the common /usr/lib/pd directory, then the 'pdextended' and
>> 'desiredata' packages would use the versions that come with  
>> 'puredata'.
>> So that means they would need to be removed from the 'pdextended' and
>> 'desiredata' packages.
>
> If "pdx" and "dd" provide "pd" and if "providing pd" includes  
> providing an
> [expr] object, then you can't do that, see above.
>
>> That's not a big deal, I am ok with that.  But
>> the problem is that if 'puredata' gets updated to 0.43 while  
>> 'pdextended'
>> is still at 0.42, and 'puredata' puts the 'extra' externals into the
>> shared directory.  Then 'pdextended' can't be 0.42 compatible  
>> anymore.
>
> You can do versioned dependencies with Debian ("Depends: pd >=  
> 0.44"), but of
> course a package that provides "X" itself cannot depend on "X >=  
> y.z" in a
> sensible way.
>
>> One idea is to package Pd vanilla's 'extra' separately, i.e. 'pd- 
>> extra'.
>> Then 'puredata' can Recommend 'pd-extra' and 'pdextended' can  
>> Conflict
>> with 'pd-extra' and I can make versioned packages for 'pdextended',  
>> ie
>> 'pd-extra042'.  Another is to have the extra folder from 'puredata'  
>> in
>> /usr/lib/puredata.
>
> "pdextended" could also a) depend on "puredata == 0.42", so that it  
> gets
> deinstalled or updated, when a newer "puredata" is installed, or

That would work, but it seems to me that it should be possible to have  
each 'pd' package independent, which I think is desireable.  I think  
that putting the docs and 'extra' stuff into each package's /usr/lib/  
(puredata, pdextended, desiredata) will work the best with the fewest  
disadvantages.  Then libraries will have their help patches with them  
wherever they are installed.

> b) it could be completely independent of "puredata" (i.e. have its  
> own "expr.pd_linux")

So how then to have shared library packages?

> c) it could conflict, replace and provide "pd" so that you can only  
> install one.

This sounds like a bad option to me, I think the problems of getting  
them working together are not very hard, we just need to agree on the  
approach.

.hc

> Maybe there are some other possibilities.
>
>
> Ciao
> -- 
> Frank
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev



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

I have the audacity to believe that peoples everywhere can have three  
meals a day for their bodies, education and culture for their minds,  
and dignity, equality and freedom for their spirits.      - Martin  
Luther King, Jr.






More information about the Pd-dev mailing list