<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Thanks Jody,<br>
      So it seems that JAI (Java Advanced Imaging) is available in
      Ubuntu Multiverse [1]?<br>
      I assume then that we should be able to package JAI dependant
      applications like geoserver into Multiverse too?<br>
      <br>
      Would multiverse be the right place to package applications like
      geoserver?<br>
      <br>
      <br>
      [1]
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <a href="http://packages.ubuntu.com/search?keywords=jai-core">http://packages.ubuntu.com/search?keywords=jai-core</a><br>
      <br>
      On 14/12/13 09:06, Jody Garnett wrote:<br>
    </div>
    <blockquote
      cite="mid:87A17F0E-19D1-4F2C-82E8-E4CC7BE28F94@gmail.com"
      type="cite">
      <pre wrap="">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

</pre>
      <blockquote type="cite">
        <pre wrap="">On 14 Dec 2013, at 6:48, Cameron Shorter <a class="moz-txt-link-rfc2396E" href="mailto:cameron.shorter@gmail.com"><cameron.shorter@gmail.com></a> 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?)

</pre>
        <blockquote type="cite">
          <pre wrap="">On 11/12/13 09:42, Angelos Tzotsos wrote:
Hi,

comments inline:

</pre>
          <blockquote type="cite">
            <pre wrap="">On 12/10/2013 11:56 PM, Alex Mandel wrote:
</pre>
            <blockquote type="cite">
              <pre wrap="">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.
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">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...
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">
Personally, I think that maintaining high
quality repository (which means regular patching of security and other
important problems) is possible only for LTS releases.
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">+1
</pre>
          <blockquote type="cite">
            <pre wrap="">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.
</pre>
          </blockquote>
          <pre wrap="">+1
</pre>
          <blockquote type="cite">
            <pre wrap="">
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.
</pre>
          </blockquote>
          <pre wrap="">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)
</pre>
          <blockquote type="cite">
            <pre wrap="">
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.
</pre>
          </blockquote>
          <pre wrap="">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.
</pre>
          <blockquote type="cite">
            <pre wrap="">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.
</pre>
          </blockquote>
          <pre wrap="">This is something I am not scared of :)
Just see how KDE works....
</pre>
          <blockquote type="cite">
            <pre wrap="">
Just to be clear, the conversation appears to be conflating a package
repository and version control repository.

Thanks,
Alex
</pre>
          </blockquote>
          <pre wrap="">Cheers,
Angelos
</pre>
        </blockquote>
        <pre wrap="">
</pre>
      </blockquote>
    </blockquote>
    <br>
  </body>
</html>