Ubuntu PPA

@praveenarimbrathodiyil and some other Debian packagers did a lot of work to package up Diaspora for Debian, perhaps there can be some reconcilation of packages that can be put in the Ubuntu PPA, considering that Ubuntu is a spinoff of Debian?

Hey folks. I found that I've got some extra spare time coming up, and I'd be interested in trying to figure out how to get the ball rolling on Ubuntu packaging. We've had a lot of wonderful work done by the Debian packaging folks, and in my mind, we have two options to go with for the PPA:

1. Port all the Debian Diaspora packages to the Ubuntu PPA.

2. Set up the Ubuntu PPA package to instead use RVM for gems.

I think we should discuss this a little, come to a decision, and find a way to get this going. There are more than a few members of the Ubuntu community that I'm sure would be more than happy to promote the PPA and the effort, and in turn help bring more attention, devs, and potential packagers to D*.

What's everyone's thoughts?

Or 3. Use bundler for dependency management. See my Archlinux package for an example.

By the way, we need more pods running the develop code and there are always users (like me :p) who want to have the most recent code possible, so I think having a package for running the develop branch but without installing the development stuff is a good idea, @jasonrobinson

Personally I would say RVM way - just to not have to care about Ruby dependencies or versions. But I would also be ready to take the Bundler way which Jonne likes.

What I would like would be two packages available;

1) diaspora-dev .. Meant for development, does not use packaged source but instead user uses own fork
2) diaspora - production package which pulls also a third package, diaspora-src which is debian packaged Diaspora* source following master branch.

Whether all this is done via bundler or RVM is really just picking details. But a big no from me for porting all gems to Ubuntu - it's too much work out of the scope of Diaspora*.

Basically, use cases;

Developers;
Install diaspora-dev with;
sudo apt-get install diaspora-dev

Then user puts their Diaspora fork username in for example .diasporarc config file and the dev environment is set up - no need for any configuration. This has mostly been done already once in the PPA.

Production env;
User installs diaspora package;
sudo apt-get install diaspora

All necessary stuff is pulled in, including MySQL/Postresql, Apache / nginx and what is needed. Configuration is done via a helper tool for podmins - or directly to Diaspora config files. The important thing is user does not need to know how to set up a pod - he/she just needs to know what domain is used, what is his admin email, basic configuration stuff.

We just need the basic packages done properly and then we can evolve.

@jasonrobinson what about a production pod but running the develop branch?

@flaburgan sure we should have that option too, but then it cannot use any source packaged in launchpad. It could install the diaspora-src package but maybe a configuration option or helper tool command could move the pod to develop branch using either the diaspora github repo OR persons own branch

Maybe it wouldn't be a bad idea to have a diaspora-dev package for Diaspora pulled from the latest develop branch, and a separate diaspora package for those wanting to run a production instance of the latest stable Diaspora release?

@seantilleycommunit I'm not sure there is a need to package Diaspora devel branch source code on Launchpad - it's way too fast moving to need packaging, why not just pull it from Github?

Master branch on the other hand is slower moving and packaging it would allow tying it to the Ubuntu Diaspora installer to make configuring easier for example.