Thanks a lot to all who responded.  I sense a strong feeling against 
introducing new Qt4-based packages right now.  And this makes sense to me.  

Given that my only motivation for a Qt4 version of these libraries is for 
DigiKam 4.x, I will propose instead to avoid the new library packages by 
bundling the sources into digikam.  This is, essentially, returning to the 
situation with DigiKam 4.4, which included sources for the following: 
libkdcraw  libkexiv2  libkface  libkgeomap  libkipi  libksane  libkvkontakte  
libmediawiki.  Some of these are currently in the archive as Qt4 versions and 
some are not.  My strategy would be to bundle the minimum necessary.

I know the Debian stance on "convenience" copies of libraries, but in this 
case (a) no-one wants or needs a new Qt4 version of these libraries, and (b) 
it is temporary as DigiKam 4.x is going away within 6 months.

Let me know if you have a better idea.

On December 22, 2015 09:58:37 AM Lisandro Damián Nicanor Pérez Meyer wrote:
> On Tuesday 22 December 2015 15:52:00 Dmitry Shachnev wrote:
> > Hi Scott,
> > 
> > On Tue, Dec 22, 2015 at 07:08:06AM -0500, Scott Kitterman wrote:
> > > It's not a new package.  It was just behind several releases and the
> > > question was to either update to the last Qt4 release or an unreleased
> > > Qt5
> > > version.
> > 
> > By “new package” I meant kgeomanip, which was never packaged.

It was never packaged independently, but was always used as part of digikam.

> As long as it doesn't depends on qtwebkit we should be fine.

DigiKam itself currently uses (Qt4-version) libqtwebkit-dev.  I saw the bug 
about it and the web page https://wiki.debian.org/Qt4WebKitRemoval
What I haven't seen is a precise time for this.  The schedule for Digikam 5 
release is May, so I (hopefully) won't need to care after that.  Is the webkit 
going to be removed before next May?


Attachment: signature.asc
Description: This is a digitally signed message part.


Reply via email to