Debian Package Distribution

[hughrawlinson]

So far, I've been able to package and distribute the current release (i.e. not master). The package for Ubuntu Trusty (14.04 LTS) is available on my packagecloud repository.

My plan of action for a more robust Debian repository solution is as follows:

1. Add Debian packaging scripts to the project repo under src
2. Set up a PPA on launchpad to put the packages in (rather than using packagecloud)
3. Set up a continuous integration service to automatically package and publish master as a "Canary" release under a separate package name (probably chuck-canary or something).

Things I would like to get done after that:

1. Automatic publishing of releases to the PPA from git tags
2. Investigate reviving the existing unmaintained ubuntu package so that users don't have to add a PPA to install ChucK.
3. Backfill the PPA with Debian binary packages for historical releases of ChucK
4. Do this whole thing again for miniAudicle.

One thing that would really help me is if Make could figure out the appropriate audio server for the target at compile time, or bake in all of the major linux audio servers to the binary. Is this possible? Has any work been done on it already? At the moment, I'm building with PulseAudio, because it's the current default in Ubuntu.

Does that sound ok?

[spencersalazar]

Thanks Hugh! That all sounds awesome. Those seem like good first steps to me.

The main thing I would add, if you have time, is to investigate an ARM version- when I looked into this, there was an option for Launchpad to do this for you if you upload source debs, so it might not be that much extra work beyond amd64 builds.

Just so I understand it, whats the issue that auto-detecting the audio backend at compile-time would solve? I think using Pulse by default is ok to start with as it is pretty standard now and this variant is usually what people want. ALSA/Jack could be separate packages or variants if apt supports that. Let me know what youre thinking here.

Run-time backend detection is interesting, at least for Pulse + ALSA, since the ALSA build has no additional dependencies beyond what the Pulse build requires. I have been thinking about how this might work for Windows (DirectSound + WASAPI + ASIO) but it could be cool in Linux also.