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

Re: [DebianGIS] [Live-demo] Ideas for Collaboration

On Thu, Apr 16, 2009 at 06:31:03PM -0700, Alex Mandel wrote:
> All,
> I think UbuntuGIS is probably a more appropriate place for most of our
> work as we are building based on the Ubuntu distro and not directly on
> Debian.
> I see why ideally live-helper is the better way to do it.
> Some notes on ubuntu modifications to get it to work right
> http://clemensfam.org/john/?p=39
> My biggest concern is whether we have enough people with the technical
> expertise. I know I've read the how to build deb tutorials/manuals a
> couple of times and still haven't been able to build a proper deb. The
> concepts are all in my head but I just haven't figured out all the
> patch/diff modification stuff and where the binary gets generated.
> For some of these projects I see why deb packages could be problematic.
> Ideally they would be in the official repos, but those don't update that
> frequently, it's kinda good that QGIS has it's own PPA  so you can get
> the latest stable asap.

Talking by experience any snapshot taken at indefinite time from DebianGis
while freezing is not in acting is a risky challenge. There are simply
too many interdependencies and very few competent people to ensure
that the resulting ensamble is not broken in one or more aspects.
That explains while resulting UbuntuGis at ubuntu freezing time
are sometimes more broken than expected.
This is not generally a big problem for live products which are 
created for demo or teaching. 
That's the reason to have an UbuntuGis team active: they have to 
ensure that the resulting set of packages are consistent and in
good shape for _ubuntu_ release. Taking packages from debian sid
and compiling them is something that a bot can do better :)

> Also, speaking from experience with some server installs. I never
> install mapserver or plone using the packages, they just have to many
> odd tweaks or missing components that make it hard to use and upgrade
> between versions. But this probably doesn't matter for the Live Disc.

In those special cases packages are useful to fix main issues and 
as a basis for additional patches and modules (see apt-build, apt-forktracer 
and friends). Also working on per-installation basis is a lost effort:
it is much better cooperating to have an (semi-)official support for 
extensions (e.g.backports, external plugins, etc.). This is not Slackware.

> I guess my vote is to try the live-helper method using the UbuntuGIS
> launchpad and PPA for building debs and possibly an osgeo trac for
> managing our config files and options.
> We should make a place for checkinstall debs created of svn trunks for
> super cutting edge in case people want those. Probably a second PPA,
> since I read that launchpad let's you have more than one now.

Checkinstall is not always able to work, be warned.

> SideNote: Talking with eipfanio, including all the common languages on
> the same disc is going to eat up a lot space, so I want to make sure
> it's easy to take the base image or config and drop the language you
> want for your particular need as a disc for that language group.

My own opinion is that a live-disc requires a weekly auto-build cycle. 
It is essentially the same case of debian-installer. A live-disc can 
be based on the current stable release in the status it is at the time 
of the build, but many things needs continuously to be updated if one needs 
up-to-date programs. Also creating a live-disc starting from testing
(or whatever you call it on the ubuntu side) can be very tricky
due to transitions. In this case it is probably much better using 
gentoo as basis (as ominiverdi did), i.e. build-from-source.

> Alex
> Cameron Shorter wrote:
> > Alex, Hamish,
> > Good to see you laying down a path forward.
> > 
> > For what it is worth, I have inherited the despot role for UbuntuGIS,
> > and am looking around for someone willing to take over the role.
> > 
> > I suspect that the UbuntuGIS launchpad could be used for the tasks you
> > are describing below?
> > If so, feel free to suggest its use, and/or volunteer for the despot role.
> > 
> > Alex Mandel wrote:
> >> I've been thinking about is some and I have a plan or at least an idea
> >> for a plan.
> >>
> >> I think we need:
> >> 1. packages built and available through standard repos or launchpad
> >> 1a. when you custom compile, instead of a make install use checkinstall
> >> which creates a deb file at least good for that system, should be fairly
> >> universal on a live-dvd, it will also show up in the package management.
> >> 1a2. Upload the deb files to a launchpad repo for install on other
> >> live-dvds. Note: these are not official deb packages and may not work on
> >> anything other than the live-dvd.
> >> 2. A script which loads and actives including gpg keys for repos that
> >> contain Geo Foss software, ie QGIS launchpad
> >> 3. A script with dpkg -l list of packages, basically run this and it
> >> will install all the geo based packages
> >> 4. A configure script, which will setup things like system user,postgis
> >> user, and maybe things like splash screen, desktop etc.\
> >> 4a. A script to add add-ons like qgis python plugins, etc.
> >> 5. A list of optional things that can be changed and how to change them
> >> 5a. Language
> >> 5b. Desktop Background
> >> 5c. Screensaver of FOSS screenshots
> >>
> >> Everything from 2+ can be stored in a version control.
> >>
> >> So the workflow would look like:
> >> 1. Download the U(X)(K)buntu variant you want to use.
> >> 1a. Install to partition or virtual machine
> >> 2. Checkout the scripts from svn
> >> 3. Run the scripts
> >> 4. Customize datasets and configuration
> >> 5. Remastersys
> >> 6. Upload/Burn
> >>
> >> A good server to upload the variants to would be nice at some point,
> >> since there are bound to be variants.
> >>
> >> What do people think?
> >> Alex

Francesco P. Lovergine

Reply to: