[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: request to backport calibre 4.16.0



Hi Matt,

Matt Taggart <taggart@debian.org> writes:

> On 5/18/20 4:14 PM, Nicholas D Steeves wrote:
>
>> Recent versions of Calibre require qtbase5-dev (>= 5.12), buster (Debian
>> 10) has 5.11.3+dfsg1-1+deb10u3, and a backport of Qt5 would break all
>> Qt5-using packages in buster.  Unfortunately this means there will be no
>> further backports of Calibre, and the existing package is technically in
>> violation of backports policy.
>
> I couldn't find anything in the upstream or debian changelogs that 
> indicate why this versioned debian dependency was added. Here's the 
> commit for the change
>
> https://github.com/norbusan/calibre-debian/commit/1041f
>
> which says
>
>     cleanup build and run deps
>
>     - unify the layout: first specific, followed by common deps
>       for both build and run
>     - add several items to build deps since we do unit testing now
>     - remove versions that are not available in Debian anymore
>
> Probably there was a reason? But has anyone tried building with older?
> In the upstream source, in ./bypy/sources.json I see
>
>     "name": "qt-base",
>     "version": "5.14.1",
>     "hashes": {
>              "unix": 
> "sha256:d9d423a6e7bcf1055c0372fc029f14a6fe67dd62c67b83095cde68b60b762cf7"
>     }
>
>
> but it comes from upstream that way, not debian.
>

Yes, IIRC I attempted to build against buster's Qt early in 2020, but by
then calibre-reader had already begun to depend on (IIRC) new qtwebkit
things.  I'm not sure if disabling compilation of calibre-reader would
do the trick, because I assume qtwebkit is used elsewhere; 'could be
wrong about this...  I'm also not sure if Calibre can be patched to use
alternative Qt 5.11 functionality; upstream would probably complain if
we did this, and I worry we'd have a new class of Debian-specific bugs.

If compilation of calibre-reader can be disabled, then a hypothetical
solution might be to split the package, create an x-ebook-reader using
the alternative system, add Provides for this to various packages, and
then backport those.  It's a lot of work for a purposefully
unintegrating (upstream will say "breaking") Calibre, but IIRC there's a
wishlist bug for a standalone calibre-reader, so this might be an
acceptable Debianish option if it wouldn't be a nightmare to maintain (I
also worry this solution would be buggy).

Do you know if there would be problems with a flatpack in combination
with apparmor?  Specifically I'm worried that dbus, udisk, and USB plug
and unplug detection will break.  It seems like it has greater chances
of success than a statically linked unofficial deb, because I seem to
remember reading that this is a case flatpack is supposed to handle
gracefully.

If anyone would like to help with realising a solution, I'd welcome it :-)

Best,
Nicholas

Attachment: signature.asc
Description: PGP signature


Reply to: