[Ubuntu] Proposal - Cleaning up dependencies/repos

[Alex Mandel]

I'll test GeoDjango with Spatialite RC from the repo this weekend. I'm
mostly concerned about known bugs in the new features of spatialite and
underlying changes to sqlite itself since I'm working right now on
developing some potential sites for deployment on Ubuntu LTS.
I believe spatialite 2.4 requires sqlite3 > 3.7.x but LTS ships with
3.6.x series and there big differences in features between those (RTree,
WAL, how a spatial db is initialized), or at least that the author is
building against 3.7.x series.

As for gpsprune, yes my ppa has ubuntugis-unstable ppa as a dependency,
though I'm pretty sure that gpsprune as a simple java app isn't using
any of them. Looking at the dependency list appears to confirm that; jre
and a java metadata lib.
http://activityworkshop.net/software/prune/
Basic story it's a gps data filtering tool. The author expressed
interest in getting it onto the next OSGeo-Live disc which is why I
grabbed the maverick package from upstream and built it for Lucid.

Thanks,
Alex

On 11/24/2010 09:37 AM, Alan Boudreault wrote:
> I agree that RCs (perhaps excepting grass) should stay in unstable. However, 
> it would be nice to know if there are real issues in qgis/geodjango with 
> spatialite 2.4 rc2 before rebuilding packages in the stable ppa. Do you think 
> you could test that? I'm also uncertain if it's a good thing to downgrade the 
> spatialite package in the repo. But if there are issues, we'll do it. In the 
> future, we will avoid to put RCs in stable.
> 
> About gpsprune, have added ubuntugis unstable PPA as dependency in your ppa? 
> If not, it would be useful to recompile your gpsprune package with the 
> ubuntugis dependencies and retest it. (btw, I have absolutely what gpsprune is 
> and what its dependencies are)
> 
> Thanks
> Alan
> 
> On November 23, 2010 05:11:05 pm Alex Mandel wrote:
>> So I ran into an interesting quagmire of dependencies.
>> The moral of the story, I would like to propose that RC candidates of
>> apps stay in "unstable" and not trickle into "stable" and maybe not even
>> into "testing" (this could be a little looser).
>>
>> Particularly the issue I ran into is that spatialite 2.3.1 isn't in the
>> repos at all, Lucid has 2.3.0 but it seems stuck on geos 3.1.0 which is
>> making my QGIS crash. I would upgrade to spatialite 2.4 RC but I'm not
>> sure that plays nice with GeoDjango yet.
>>
>> So under my idea
>> Stable would have 2.3.0 or 2.3.1, QGIS 1.5(Could be upgraded after we
>> know 1.6 is safe)
>> Testing would also have 2.3.1, QGIS 1.6
>> Unstable would have 2.4 RC x
>>
>> That way in testing there would be a nice reliable set of QGIS, gdal,
>> spatialite etc that are known to be fairly good and unstable would have
>> more cutting edge stuff. I realize maverick included spatialite 2.4RC
>> and think that may have actually been a mistake since the author admits
>> it's a bit buggy (not to say 2.3.x series doesn't have it's issues). But
>> more importantly some underlying changes could cause issues for QGIS,
>> GeoDjango etc. In summary having some slightly older version no longer
>> available in Debian or Ubuntu might actually be a + to the everyday user
>> if the distro jumps the gun on an app(in stable of course).
>>
>> This needs a little fine tuning obviously since GRASS tends to have
>> really long release cycles and maybe could be summed as the "testing"
>> ppa has the last known stable release.
>>
>> Any thoughts?
>>
>> Thanks,
>> Alex
>>
>> PS: I'm more than willing to help package, just still new at it. Looks
>> like gpsprune for Lucid worked and I would love to have that copied to
>> ubuntugis.
>> _______________________________________________
>> UbuntuGIS mailing list
>> Ubuntu at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/ubuntu
>> http://trac.osgeo.org/ubuntugis/wiki
>