[PD] Pd packaging on osx was: Re: [PD-announce] [osx] pd++0.39-1Beta available

[Hans-Christoph Steiner]

I see little advantage to this complexity.  Why do you need to update  
only parts of the Pd.app?  Why not just download a whole new Pd.app?   
Bandwidth is cheap enough these days.  Having a build that has  
consistent versions of the various bits of code that are known to work  
with each other is huge.

If someone really needs such a specifically tailored Pd.app, it would  
be easy enough for them to do it themselves by copying the *.pd_darwin  
files into place.

.hc

On Oct 30, 2005, at 9:55 AM, B. Bogart wrote:

> Hey all,
>
> I've finally gotten to this thread.
>
> Anyhow I think Lorenz's proposal of having multiple packages does make
> sense for upgrading, but there is still something to be said for the
> ease of installation with everything included. For example my
> pixelTANGO.app (which will be part of the main release eventually) is
> messed up once and a while because people don't read the instructions  
> to
> drag and drop the directory and the plist file.
>
> If the .app was totally modular then it would make the installation  
> that
> much worse, to install say 4 packages to get a fully loaded pd as  
> before.
>
> Mind you if we could combine the OSX pkg and mpkg stuff with the .app
> then we may be able to do something where there is a single  
> installation
> that installs all the required modules automagically (extra externals,
> flext pdp etc..) and still being easy for the user. This would be back
> to an installer though, which simply includes a .app.
>
> Then in the future one (correct me if I'm wrong) upgrade say only the
> flext external modules, only Gem, only the CVS externals seperatly...
> Maybe even reinstalling PD itself but using the old externals. (if
> possible).
>
> Until there is a ppc pure::dyne (I'm not holding my breath) seems the
> .app is the best way to get people into PD as fast and painless as
> possible.
>
> .b.
>
> Lorenz Schori wrote:
>> hi
>>
>> different pd versions: actually i wonder how pd/linux deals with this
>> problem. does msp version look into other paths as devel? are they
>> configured at runtime? i thougth about an additional standard path in
>> osx determined at compile time from the version information (like "~/
>> Library/Application Support/Pd/0.39-msp/extra" + "~/Library/  
>> Application
>> Support/Pd/0.39-msp/doc").
>> fink: i think it would be easy to just pack debians and throw it into
>> fink. for advanced users (with several pd versions/flavours) this   
>> would
>> be fine. however the advantage of the pd.app is that pd files  get
>> double-clickable on desktop and messing around with the command  line
>> will not be nessesary. i think for most osx users it would be
>> comfortable to just link the externals statically with the requred
>> libraries.
>> flext: i don't know if this is possible and i'm not sure if this   
>> makes
>> sense: how about just linking flext statically into pd binary?  if i
>> have to compile flext for each pd version/flavour anyway i don't  see  
>> a
>> drawback to just include it (appart from eventual stability  issues).
>>
>> lorenz
>>
>> Am 24.10.2005 um 17:33 schrieb Frank Barknecht:
>>
>>> Hallo,
>>> Lorenz Schori hat gesagt: // Lorenz Schori wrote:
>>>
>>>
>>>> it is certainly not the goal to make things more complicated nor to
>>>> include less stuff. what i propose is just to move the externals out
>>>> of the package into a more accessible, managable and natural (for  
>>>> osx
>>>> users) place, plus to modularize externals a bit (standard/gem/pdp/
>>>> flext/...). this way it will be easier to upgrade pd and different
>>>> external packages independantly from each other.
>>>>
>>>
>>> But is there a way to handle dependencies as cleanly as e.g. Debian
>>> does it? For example you would need different flext packages for
>>> pd-devel and ps-MSP, IIRC. Some externals which use private headers
>>> may need to be recompiled for a a new upstream version. With a single
>>> package it is easy for Mac users to get matching versions of
>>> everything.
>>>
>>> I guess it would be the best to get in contact with the Fink team and
>>> provide regular Fink packages of Pd and Pd externals?
>>>
>>> Ciao
>>> --
>>>  Frank Barknecht                 _ ______footils.org_ __goto10.org__
>>>
>>> _______________________________________________
>>> PD-list at iem.at mailing list
>>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/
>>> listinfo/pd-list
>>>
>>>
>>
>>
>> _______________________________________________
>> PD-list at iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->  
> http://lists.puredata.info/listinfo/pd-list
>

________________________________________________________________________ 
____

"[W]e have invented the technology to eliminate scarcity, but we are  
deliberately throwing it
away to benefit those who profit from scarcity."
                                                                          
        -John Gilmore