Re: Bug#712688: transition: gdal
- To: email@example.com
- Subject: Re: Bug#712688: transition: gdal
- From: Ivan Mincik <firstname.lastname@example.org>
- Date: Tue, 31 Dec 2013 15:29:51 +0100
- Message-id: <[🔎] 52C2D4DF.email@example.com>
- In-reply-to: <20131122172312.GA6250@homebox.lovergine.com>
- References: <firstname.lastname@example.org> <20130618151603.GH5651@blegrez.ba.issia.cnr.it> <20130709220139.GC28839@betterave.cristau.org> <20130710081650.GA4163@blegrez.ba.issia.cnr.it> <20131122172312.GA6250@homebox.lovergine.com>
-----BEGIN PGP SIGNED MESSAGE-----
On 11/22/2013 06:23 PM, Francesco P. Lovergine wrote:
> On Wed, Jul 10, 2013 at 10:16:50AM +0200, Francesco P. Lovergine
>> On Wed, Jul 10, 2013 at 12:01:39AM +0200, Julien Cristau wrote:
>>> On Tue, Jun 18, 2013 at 17:16:03 +0200, Francesco P. Lovergine
>>>> On Tue, Jun 18, 2013 at 04:27:41PM +0200, Francesco Paolo
>>>> Lovergine wrote:
>>>>> BTW, without annoying all of you with a so looooooong
>>>>> history about this issue, I'm going to introduce a new
>>>>> libgdal1h binary package (h means hidden, better
>>>>> suggestions are welcome :)), with a new SONAME libgdal.1h
>>>>> to manage a decent migration to the new flavor. This will
>>>>> sacrifice third-parties sw compatibility, but well, who
>>>>> cares? It would be break anyway.
>>>> Maybe a better choice in this specific case would be
>>>> introducing a new binary package (libgdal1h) that
>>>> Conflicts/Breaks against libgdal1 and provides the usual
>>>> library with the usual name/soname. Of course, that will
>>>> force a lot of bNMUs and an explicit unblocking set to
>>>> complete the transition properly. Make sense?
>>> I must admit from your mails I don't really understand what
>>> your plan is. Do the packages currently in experimental follow
>>> that plan?
>> Yes, at least the still pending in NEW queue (it has a proper
>> fix). I would simply provide a new libtary package that provides
>> the usual library name/soname and conflicts with the old one.
>> That will require a good amount of bNMUs for rdepends.
> After a couple of new releases in experimental, it is now time of
> pushing this change ASAP in sid. RMs, could you please give an ack
> about that? As said, we will need to ask for a long list of bNMUs
> after release in sid.
Dear Francesco and Bas, I was trying to read all possible information
(bug reports, debian/changelog, mailing list) about the libgdal1h
issue and transition, but still, it is not clear for me what the
current state is and what it needs to be done to complete this task.
Please, could you summarize current situation ? Is it possible that
GDAL 10 packaging will be fully completed soon enough to get to Ubuntu
14.04 LTS in best shape ?
Thanks a lot for your work.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----