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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@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