Re: Bug#712688: transition: gdal
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.
--
Francesco P. Lovergine
Reply to: