On 11/11/2013 12:42 PM, Johan Van de Wauw wrote: > On Sat, Nov 9, 2013 at 10:19 PM, Ivan Mincik <ivan.min...@gmail.com> wrote: > >> >> I You think about it, my proposal to PPA structure is following: >> >> * ubuntugis-development - development versions of packages. Package version >> changes until they move to 'ubuntugis-staging' >> >> * ubuntugis-staging - staging versions which will be prepared to move at the >> time of each new ubuntu distribution release to 'ubuntugis-stable' >> >> * ubuntugis-stable - packages for all ubuntu distributions (LTS an non LTS) >> which will never change versions for a particular ubuntu distribution once >> released (only bugfixes available) - packages for each new distribution will >> be uploaded at the time of ubuntu distribution release >> Packages will be supported for each ubuntu distribution life time. >> > ... >> Maintaining packages in 'ubuntugis-stable' for LTS distributions is >> long-term, responsible and boring task. This task I see as candidate for >> dedicated maintainer which could be financially supported by companies or >> organizations. > Ideally these packages should not be in a ppa but in universe (ubuntu > itself). If we keep in sync with debiangis the maintenance of these > packages will be much easier and not duplicated >
That's a great thought but a little of the mark. My servers are indeed LTS but I use/need postgis 2.0 and gdal 1.10 which are not in universe and if we're lucky might make Ubuntu 14.04 The ppa infrastructure works pretty well for keeping this going on new enough versions without having to be all self compiled. Part of the reason I don't use Redhat/Centos is they are almost always 3 years behind on sensible packages and then keep that release like that for a long time. ie even Postgis 1.5 on those platforms or Python 2.7 is a royal pain sometimes. > I think maintenance in the first place this is not a role for > ubuntugis but for the project itself. I don't think it is good that > someone outside the project keeps patches, ... Ideally a project > should have maintenance releases as eg geoserver has. Usually no > packaging changes are needed for maintenance releases, so the > remaining job for debian/ubuntugis is not that hard. > Some members of Debian/Ubuntugis are the official packagers for some projects for these distros. Yes, I agree usually little change to a package should need to occur, but I've still not successfully repacked a single point release for even simple projects (I tried GDAL a few times on my way to learning to do it for QGIS). See more on this below. > In fact if we have a package in universe, it may not be uncommon that > security updates published by the projects are processed by motu's > employed by canonical. > In short, rather than duplicating work I think we should work more > with ubuntu to make sure recent packages are added and supported. > A Java package is a bad example. New releases (1.8 to 1.9 to 1.10) of GDAL sometimes requires GRASS, QGIS and Postgis to be rebuilt in order for those new fixes/formats to come in. These types of changes are more than Ubuntu would normally allow within regular updates as they are mostly not security but feature updates (there may be some exceptions on LTS now). Yes, most of the packages are in universe, and if you look at the description pages http://packages.ubuntu.com/saucy/qgis You'll see that Ubuntu Motu get them from DebianGIS. So part of the key to this keeping DebianGIS up to date, which often times is harder than keeping Ubuntu ppa's up to date. Or we can work with the Motu to use Ubuntugis to get their updates. >> >> * ubuntugis-backports - backported packages for LTS distributions. Can be >> upgraded as time goes on for all distributions > > I think it is better not to have a seperate backports archive. I think > the development/staging packages should just exist for every release > we intend to support. > It also seems more practical for an end-user. He/She adds the ppa once > to get more recent versions of gis software than provided in universe. > Now you ask him/her to add this ppa, and then at one point in the > future to add the backports archive. > Having an extra ppa also increases the number of scenarios we have to > support: universe, universe+staging, universe+backports, > universe+staging+backports. Instead of 1 you get 3 combinations next > to universe. This becomes almost impossible to test every upload > especially if you take into account different ubuntu releases. I agree we probably don't want more ppa's just better naming and planning. Here's how I think of it and examples of what would be in each: Staging or Development aka Testing <- Anything new that needs to be test built or is not a final release Newer or Backport or Latest Stable aka Unstable <- Latest official release from a project Stable or Archive <- Slightly older major release from project, moved from Unstable into here before something new gets put in Unstable, assuming it's newer than Ubuntu universe Specific to 12.04 Precise ( some of the stable packages wouldn't be necessary at all in Saucy ) Example: QGIS-dev QGIS 2.0.x QGIS 1.8.x (because qgis 1.7.x was in universe) Example: Postgis dev Postgis 2.1.x Postgis 2.0.x (because postgis 1.5 is in inverse) Example: GDAL dev GDAL 1.10.x GDAL 1.9.x (because gdal 1.7.x is in universe) Example: SAGA dev SAGA 2.10 SAGA 2.0.8 (universe has SAGA 2.0.7) <- this is the one case where universe probably could push an update if it went via the right channels. This formula allows users to upgrade when they are ready for it. ie I'm still using QGIS 1.8 on some desktops because 2.0 broke important functionality that 1.7.4 never had but I expect that 2.1 or 2.0.2 might have those fixed (since they are known regressions). But I'm just doing it by keeping the Stable repo instead of Unstable. Soon as GDAL 1.11 is official though the question becomes do we bump GDAL 1.9 out of stable? or only bump it out of stable for some releases (newer than x?) Nightly or Dailies should each have their own ppa per project if someone wants to maintain them with recipes. Thanks, Alex _______________________________________________ UbuntuGIS mailing list Ubuntu@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/ubuntu http://trac.osgeo.org/ubuntugis/wiki
