[PD] Pd packaging on osx was: Re: [PD-announce] [osx] pd++0.39-1Beta available
hans at eds.org
Tue Nov 1 06:27:22 CET 2005
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.
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
> drag and drop the directory and the plist file.
> If the .app was totally modular then it would make the installation
> much worse, to install say 4 packages to get a fully loaded pd as
> 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
> 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
> 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
> Lorenz Schori wrote:
>> 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/
>> 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
>> 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
>> flext: i don't know if this is possible and i'm not sure if this
>> 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
>> drawback to just include it (appart from eventual stability issues).
>> Am 24.10.2005 um 17:33 schrieb Frank Barknecht:
>>> 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
>>>> 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
>>> 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?
>>> Frank Barknecht _ ______footils.org_ __goto10.org__
>>> PD-list at iem.at mailing list
>>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/
>> PD-list at iem.at mailing list
>> UNSUBSCRIBE and account-management ->
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it
away to benefit those who profit from scarcity."
More information about the Pd-list