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

B. Bogart ben at ekran.org
Sun Oct 30 15:55:02 CET 2005


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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20051030/78a9641c/attachment.pgp>


More information about the Pd-list mailing list