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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
