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

Re: [Sc-devel] 3.2 packaging

Wait a minute, I don't understand what's being discussed here: are
these changes expected to go into 3.2? It sounds like quite a
significant change and we're already about a week late in fixing the
first release candidate.

If these changes affect the build of SC 3.2 at all then we shouldn't
do them, they've missed the boat. If we're just discussing whether or
not to put quarks into the package downloads, or exactly how to put
together the OSX installer package, then fine.


2008/1/27, Scott Wilson <i@xxxxxxxxxxxxxx>:
> 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.
> _______________________________________________
> Sc-devel mailing list
> Sc-devel@xxxxxxxxxxxxxxx
> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel