Re: Bug#712688: transition: gdal
On Wed, Jul 10, 2013 at 10:16:50AM +0200, Francesco P. Lovergine wrote:
> 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 wrote:
> >
> > > 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.
--
Francesco P. Lovergine
Reply to: