Adding build profiles to Debian GIS packages

Sebastiaan Couwenberg sebastic at xs4all.nl
Sat Jan 23 10:36:32 UTC 2016


On 23-01-16 11:17, John Paul Adrian Glaubitz wrote:
> On 01/23/2016 10:30 AM, Sebastiaan Couwenberg wrote:
>> Many of our packages? Do you have specifics, because I'm only aware of
>> two circular dependencies which only affect a small subset of our
>> packages (but include the most important ones)?
> 
> I have around 15 packages which depend directly or indirectly on
> gdal and are currently BD-Uninstallable because gdal is
> BD-Unsintallable:

So nothing new. Most GIS packages depend on gdal, making this fallout
expected.

>> https://buildd.debian.org/status/package.php?p=gdal&suite=sid
> 
>> I don't have time to look into build profiles now, and I expect them to
>> only be useful in the sort terms until librt-topology can be used
>> instead of liblwgeom for spatialite. Motivating the rt-topology devs to
>> release seems more fruitful than investing time into build profiles that
>> won't be used long.
> 
> Build profiles aren't normally difficult to implement for most package
> maintainers as they know which features they can temporarily turn
> off during bootstrapping. I assume that complete rebootstrappability
> is going to be a release goal at some point. Maybe not for Stretch
> but maybe for Buster because we really need to get the archive in
> a shape where we can bootstrap onto a new architecture without
> lots of manual internvention.

Building spatialite without liblwgeom support causes removed symbols
breaking the build. We need build profiles aware symbols file or similar
for spatialite to deal with that.

>>  I'm not aware of upgrade problems caused by the current situation, if
>>  they exist and are common we should consider dropping the liblwgeom
>>  dependency already and live with the reduced functionality. But as far
>>  as I can tell that isn't the case.
> 
> Check your packages on any of the ports architectures, they are
> BD-Uninstallable on all of these. I have tried to untangle the
> dependency mess but I failed with the amount of time spent.

I recommend any other porters to not bother with these circular
dependencies as they are expected to be temporary (until we can switch
spatialite to rt-topology). Additionally the GIS packages are such a
niche that actual users of these packages on the ports are not expected
to exist.

> So, before spending much more time on the issue, I thought it might
> be a good idea to ask the package maintainers for help. I would
> like to get your packages build on these architectures, but I currently
> don't know how to resolve the circular dependency.

Now you do, the procedure is described in the geos transition bugreport.

But please spend your time on more important packages, which the GIS
packages are not.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



More information about the Pkg-grass-devel mailing list