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

[Vincent Lefevre]

Control: reopen -1
Control: affects -1 nomacs

I'm reopening the bug because it also affects nomacs (though much
less seriously since a better metadata is used by nomacs), and this
time, this is a bug introduced on the Debian side: nomacs ships with
exiv2 0.27.2, and it is Debian's choice to link with exiv2 0.27.3.

Before upgrading to the incompatible version exiv2 0.27.3, this
should have been discussed with the nomacs maintainers.

For nomacs, I've opened a bug there:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974616

in case they wish to update the nomacs source (and differ from
upstream).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#971879: [Pkg-kde-extras] 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

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