[Pkg-kde-extras] Bug#971879: Bug#971879: Bug#971879: gthumb: "charset=Ascii" appears before the comment of the image

[Pino Toscano]

retitle 971879 "charset=Ascii" appears before the comment of the image
severity 971879 normal
thanks

In data giovedì 12 novembre 2020 23:33:17 CET, Vincent Lefevre ha scritto:
> On 2020-11-12 22:48:32 +0100, Pino Toscano wrote:
> > This is not how SONAME works, especially in a binary distro like Debian.
> > Even assuming an SONAME bump is due (which IMHO is not), the consequence
> > will be:
> > 1) the SONAME of the library is bumped, either by upstream or in Debian
> > 2) the Debian package is renamed
> > 3) exiv2 will go through NEW
> > 4) there will be a new exiv2 transition, and all the packages using the
> >    exiv2 library will be rebuilt anyway (including gthumb)
> > 5) we are back to the same situation
> 
> Not really. The applications should notice the change of the API via
> their testsuites (if the build does not fail in the first place),
> because they do not get the expected result. [...]
> Now, it appears that in the particular
> case of gthumb, its testsuite does not detect the issue. :( I don't
> know about the other applications, though.

That is not that much different than any other API or behaviour change.

> So, what happens in
> practice is that both versions of the library are coinstallable, and
> applications that do not support the new API yet can still use the old
> library until support is added.

That only works for your local system, not for the Debian archive.
If gthumb will not build during a library transition (for whichever
reason, API change or test suite failure), then either it is fixed to
build, or it will be removed from testing until it is fixed.
The exiv2 source is one, and it provides only a library package.

> > This is a behaviour change of the API, and IMHO there are two only
> > options:
> > a) restore the old behaviour, optionally adding a new API if needed
> > b) adapt the applications to the new behaviour of the API
> > 
> > Considering that it seems a wanted change by upstream, then I don't
> > see (a) happening, so (b) seems to me the only alternative. Sure,
> > it is not nice, but meh, not something else to do.
> > 
> > Because of the above, Vincent, what about closing this bug, since there
> > is nothing actionable in exiv2?
> 
> I think that the best workaround is to temporarily restore the old
> behavior until the applications support both the old one and the
> new one.

That would mean changing the behaviour for all _the_ exiv2 users,
including the ones that adapted to the new behaviour. Also, this is
definitely not a kind of change that I will apply locally in Debian,
since it will make exiv2 behave differently than how upstream does,
and how applications expect.

Sorry, but unless upstream changes the behaviour, then the only viable
solution is adapting the applications. Definitely this is *not* an
rc-bug, though, especially with a misleading reason.

-- 
Pino Toscano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://alioth-lists.debian.net/pipermail/pkg-kde-extras/attachments/20201112/934c483e/attachment.sig>