[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 ;-)