Re: libspatialite3 deps
On 03/13/2014 12:24 PM, Francesco P. Lovergine wrote:
> On Mon, Mar 03, 2014 at 12:48:14PM +0100, Sebastiaan Couwenberg wrote:
>> QGIS and friends are currently built against SpatiaLite 3.x because that
>> version is still in unstable. In experimental we have SpatiaLite 4.1.1
>> which is waiting for a transition slot from the release team:
>>
>> [...]
>>
>> When we get the go ahead from the Release Team QGIS and friends will be
>> BinNMU'ed to build with SpatiaLite 4.1.1.
>>
>
> Hi Bas, isn't that the case to push spatialite & friends? Waiting RMs ok
> in this phase of the release workflow is quite pointless.
To speedup the process of getting the new versions in unstable it's an
option. I'm not happy with the time it takes to get the go ahead, but I
also don't want to do an uncoordinated transition, at least not make
that decision. I'm tempted to put it up for a vote, if the majority of
the team thinks it's a good idea, we should go ahead anyway and leave
the transition for unstable to testing only.
As someone dependent on sponsors to get packages uploaded to the
archive, I'm not looking forward to the lectures that will follow my
RFSes for the uncoordinated transition.
Following the proper procedure in Debian takes time, we're notorious for
that. But I take comfort in the text of my favorite Debian t-shirt:
"Good things come to those who wait". I'm willing to spent the time to
follow proper procedure even though it's a bit inconvenient. I'd rather
do things correctly than quickly.
Because the packages are ready for the transition, Ubuntu has synced
them from experimental. Debian testing and unstable remain the sole
distributions with SpatiaLite 3.x. To get the updated packages in the
hands of users it's arguably a good idea to not wait much longer to
upload them to unstable.
With the osgEarth 2.4 and QGIS 2.2 upgrade in the pipeline, I want to
focus on completing that first. The armhf buildd finally got around to
building QGIS 2.2, but failed again while generating the API docs. So I
need to fix that first. I definitely don't want to do the uncoordinated
SpatiaLite transition with QGIS 2.2 still in experimental. Uploading
QGIS 2.2 to unstable as part of the uncoordinated transition has my
preference if we chose to go that route.
Despite my reservations, performing the uncoordinated SpatiaLite
transition in unstable may be in the best interest of our users.
Kind Regards,
Bas
--
GPG Key ID: 4096R/E88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Reply to: