[Live-demo] Kick-starting OSGeoLive 7.5 - packaging for .deb

[Cameron Shorter]

Thanks Jody,
So it seems that JAI (Java Advanced Imaging) is available in Ubuntu 
Multiverse [1]?
I assume then that we should be able to package JAI dependant 
applications like geoserver into Multiverse too?

Would multiverse be the right place to package applications like geoserver?


[1] http://packages.ubuntu.com/search?keywords=jai-core

On 14/12/13 09:06, Jody Garnett wrote:
> We do not qualify for deb repositories due to JAI. You can produce stuff for apt get and yum but you would need your own repo ( as Boundless has done ).
>
> --
> Jody Garnett
>
>> On 14 Dec 2013, at 6:48, Cameron Shorter <cameron.shorter at gmail.com> wrote:
>>
>> Hi Jody,
>> For our next OSGeo-Live release, packaging will be a major theme, which ideally will lead to most/all OSGeo-Live applications being available in Ubuntu GIS, leading to easier access for a greater community.
>>
>> I'm keen to hear your thoughts on the .deb packaging on java applications. You might want to CC in other Java thought leaders too. (this email thread comes from the osgeo-live list, which I assume you are subscribed to and can respond to on list?)
>>
>>> On 11/12/13 09:42, Angelos Tzotsos wrote:
>>> Hi,
>>>
>>> comments inline:
>>>
>>>> On 12/10/2013 11:56 PM, Alex Mandel wrote:
>>>>> On 12/10/2013 01:37 PM, Ivan Minčík wrote:
>>>>> I would like to note a few things.
>>>>> Creating and maintaining DEBs for all apps can be a huge task.
>>>>> Theoretically, if it would be done, it needs to be re-maintained every time
>>>>> when a new release is done (or does it make a sense to release without
>>>>> updating apps ?). Updating packages at every OSGeoLive release means also
>>>>> that it needs separate repository. This means another Debian GIS repository
>>>>> fragmentation (Debian GIS, UbuntuGIS, QGIS Debian repo, others ...) and
>>>>> less cooperation between projects. I think it is really important to join
>>>>> forces of all Debian and Ubuntu GIS groups together [1] and make agreement
>>>>> on rather less frequent but high quality common repositories.
>>> At this point DebianGIS and UbuntuGIS cannot accept Java binaries to be transformed into deb. I know because I have similar issues with RPM systems. In RPM world the solution is to deploy a separate repository outside the distribution and create the files needed. Can we use a "non-free" repository from Debian/Ubuntu to upload deb files which are produced from war repackaging?
>>>
>>> Just to clear things out: I AGREE that binaries should not be included in systems like Launchpad and OpenBuildService to keep control that a distribution can be built completely from source. Practical reasons for OSGeoLive dictate that we need packages from binaries though...
>>>>> Personally, I think that maintaining high
>>>>> quality repository (which means regular patching of security and other
>>>>> important problems) is possible only for LTS releases.
>>> +1
>>>> We should not be maintaining our own repo/ppa for anything that isn't
>>>> specifically osgeo-live. That means only build scripts, documentation
>>>> and data extractions are candidates. All 3 of these can happily live in
>>>> the same repo/ppa. Software should always come from already existing
>>>> sources as much as possible.
>>> +1
>>>> I agree that we need to stick to every 6 months. It's things like QGIS,
>>>> Geoserver, Leaflet, OpenLayers, geos, gdal, etc that are constantly
>>>> changing and people always want the latest version (Note Geoserver is
>>>> doing timed 6 mo releases). Long time stable software (I'm not going to
>>>> call it Core because that will only lead to confusion) is already simply
>>>> pulled from Ubuntu directly where it comes from Debian to begin with (ie
>>>> GMT).
>>>>
>>>> As for Java packages, geonode/geoserver have demonstrated there is a way
>>>> to still use ppa's even if the java source doesn't make it quite there
>>>> at this time. We should not maintain our own debian style repo, thats
>>>> way too much extra work when launchpad does it for us.
>>> For GeoNode there are 2 packaging efforts: One is based on Jenkins and creates deb from GeoServer war (similar to what I propose above) and the second is ppa based and creates packages for python parts of GeoNode (it will work with a vanilla GeoServer running on 8080 but it does not include this in the deb)
>>>> I think Angelos was thinking Docs/Translations needed to be split into
>>>> it's own VCS. This is partly driven by wanting to use Transifex.
>>> This is true, I would also prefer to move to git.
>>>
>>> We could also use separate VCS for the rest: e.g. we could use a git repo to keep the debian files needed to create the deb packages. Perhaps this git repo can be the base for UbuntuGIS project too. Just a thought.
>>>> The
>>>> biggest downside is maintaining multiple versioning systems, which also
>>>> could cause the docs/translation to be out of sync with the the actual
>>>> releases unless we're careful to tag/branch specific to a release cycle
>>>> and only pull the docs for that release.
>>> This is something I am not scared of :)
>>> Just see how KDE works....
>>>> Just to be clear, the conversation appears to be conflating a package
>>>> repository and version control repository.
>>>>
>>>> Thanks,
>>>> Alex
>>> Cheers,
>>> Angelos

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/live-demo/attachments/20131214/e1c6ded1/attachment.html>