[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sc-devel] 3.2 packaging




On 27 Jan 2008, at 05:39, Click Nilson wrote:

I think we should resolve the status of 3.2 too; at what point will a simple download be available on sourceforge? When do we tag the source and when is testing officially over? Afraid I don't know how to tag the source tree, and how to best motivate you all through a testing regime ; ) I just know we need to resolve this soon.

On the extensions issue, I would just have the extra directory for all third party libraries/quarks/extensions in the SC application folder (and not installed by default), and let the user then place them where they like; maybe have some quark or quark like functionality to put symbolic links in the platform specific extensions as before.

This seems unnecessarily flexible to me (why do I need to put them anywhere?) and complicates installation and configuration. IIRC, quarks need write access to their directory, so linking to them in the applications folder means yet more potential permissions issues. I'm in favour of moving synthdefs and recordings into the application support directories as well for this reason. It would make more sense to have the installer put everything there, and make symlinks to them in the application directory.

. OR, we just offer a package with the extensions in the SuperCollider_f folder and a README.

So this is the option that seems to require the least future support and causes least messiness on machines. Particularly for those who have multiple versions of SC around!

I think some of this really arises from the current state of affairs and will be much simpler once a few issues are resolved. It seems to me:

- Any extension we include in the distribution should be a quark (this needs the UGen issue to be sorted, yes?) - There should be a package so installation can be simple and automated for new and general users. - Since quarks are versioned the installer can check this and overwrite as appropriate. - The multiple versions issue really comes down to the need to selectively include extensions at compile time, yes? We need a mechanism for this. - People who have the multiple versions issue are likely developers, and know how to deal with extensions, accounts, etc. manually if needed. It's more important to make life simple for general and new users than for us (I say at the risk of re-igniting the great quarks svn debate of 2007 ;-)

S.