This package has Build-Depends on GTK 2 (libgtk2.0-dev), or produces
binary packages with a Depends on GTK 2.

GTK 2 was superseded by GTK 3 in 2011 (see
<https://bugs.debian.org/947713>). It no longer receives any significant
upstream maintenance, and in particular does not get feature development
for new features like UI scaling on high-pixel-density displays (HiDPI)
and native Wayland support. GTK 3 is in maintenance mode and GTK 4 is
approaching release, so it seems like a good time to be thinking about
minimizing the amount of GTK 2 in the archive.

GTK 2 is used by some important productivity applications like GIMP, and
has also historically been a popular UI toolkit for proprietary software
that we can't change, so perhaps removing GTK 2 from Debian will never be
feasible. However, it has reached the point where a dependency on it is
a bug - not a release-critical bug, and not a bug that can necessarily
be fixed quickly, but a piece of technical debt that maintainers should
be aware of.

A porting guide is provided in the GTK 3 documentation:
https://developer.gnome.org/gtk3/stable/migrating.html

Some libraries (for example libgtkspell0) expose GTK as part of their
API/ABI, in which case removing the deprecated dependency requires
breaking API/ABI. For these libraries, in many cases there will already
be a corresponding GTK 3 version (for example libgtkspell3-3-0), in which
case the GTK 2-based library should probably be deprecated or removed
itself. If there is no GTK 3 equivalent, of a GTK 2-based library,
maintainers should talk to the dependent library's upstream developers
about whether the dependent library should break API/ABI and switch
to GTK 3, or whether the dependent library should itself be deprecated
or removed.

A few packages extend GTK 2 by providing plugins (theme engines, input
methods, etc.) or themes, for example ibus and mate-themes. If these
packages deliberately support GTK 2 even though it is deprecated, and
they also support GTK 3, then it is appropriate to mark this mass-filed
bug as wontfix for now. I have tried to exclude these packages from
the mass-bug-filing, but I probably missed some of them.

Regards,
    smcv

Hi,

with GTK2 scheduled for removal in the next Debian release and the bug
#967842 being release-critical, it seems we need to think about the
future of xzgv in Debian.

As far as I can tell, there is no active upstream anymore, and I am not
aware of ongoing efforts to port xzgv to GTK3 or GTK4. Given this
situation, continuing to ship it in the next release might become
difficult once GTK2 is gone.

Yesterday I ran into a somewhat comparable situation with sxiv (also
with orphaned upstream), where Debian provides nsxiv as a drop-in
replacement. In that case, introducing /etc/alternatives/sxiv and
letting nsxiv provide sxiv offers a reasonably smooth transition path.

For xzgv, I do not immediately see such a straightforward replacement.
However, I wondered whether geeqie might cover at least a similar use
case for most users. Do you think that would be a sensible migration
path, or do you see better options?

If removal becomes unavoidable, it might be helpful to provide users
with some guidance in advance. I would be interested in your view on how
best to handle this, in a way that respects the package’s history and
its users.

What are your thoughts?

Kind regards
   Andreas.

Hi!

I switched from xzgv to geeqie some years ago, it has the same kind of
interface, it’s fast, and you can use it to sort your picture, using
marks, and “move to directory”.

If you are looking for an alternative, it might be a nice upgrade.

Nicolas.

Thanks for reaching out.  Because of GTK2 going away, this is
something that I've been considering.

I wasn't aware of nsxiv and geeqie as possible alternatives for xzgv,
so I appreciate your raising them as alternatives.

Based on how I use xzgv personally, I find nsxiv to be a closer match
for me, although it doesn't have the file browsing feature which
geeqie does have --- although I do find how they implement them to be
quite annoying.

Quoting from the xzgv man page:

   If started with `xzgv files', xzgv hides the file selector and
   treats the file or files as if they were the sole contents of a
   directory. (It also automatically loads the first file.) As such,
   you can use the Next Image and Previous Image commands to navigate
   between the images, or do Exit to Selector and use the selector
   directly.

So something like "xzgv ~/www/*.jpg" works much like "nsziv
~/www/*.jpg".  The command-line options and keyboard accelerators are
different, of course, but that's going to be pretty inevitable when
switching between image viewing programs.

Since nsxiv doesn't have a file selector, if what you are doing is
"xzgv ~/images/" that's where "geeqie ~/images" is a much closer
match, and I'm guessing that's why you were suggeseting geeqie as a
potential alternative for xzgv.

The use case where geeqie has an... interesting UI choice is when you
run "geeqiee ~/www/*.jpg".  The file selection page on the sidebar
lists *all* of the files in ~/www, with the *.jpg files highlighed,
making it hard if you want to switch between the various image files
since there would be a huge amount of *.html files in the selection
window getting in the way.  Interestingly, if you hide the file
selection sidebar using C-h (or the equivalent menu bar option), and
the unhide the file selector, the *.jpg files are no longer
highlighted, and when you try to step through the image files, geeqie
will attempt to display the HTML files.

And if you do something like "geeqie ~/www/*.jpg ~/Images/*.jpg" it
does something even stranger, which I haven't completely figured out,
but it's not actually something I find helpful (or even intuitive,
since I'm not even sure what it's trying to achieve).

So from the perspective of my own personal use, I would probably never
use geeqie, but pick nsxiv instead.  However, there may be some xzgv
users who would find "geeqee ~/Images" to be what they want.

Hmm... perhaps eog ("eye of gnome") might be a better suggested
replacement for xzgv?  Its image gallery is not quite a replacement of
the file selector, as it shows thumbnails instead of filenames, but
it's close.

							- Ted

Hi again,

Am Sat, Feb 21, 2026 at 04:21:50PM -0500 schrieb Theodore Tso:

How do we go from here.  I think we have no chance to distribute xzgv
with Debian 14.  So we probably need to ask for removal of this package
(to my exerience its easier to convince the archive team if this is done
by the maintainer).  Given that we have quite a number of packages using
GTK2 I would love to help our users to migrate in a sensible way.

Finally users need to decide, but do you see some sensible migration
path?  Or is just removing the package and let users find out themselves
the only feasible option.  I actualy have no idea but if the latter
is the case it might be better to remove it rather sooner than later
to have a large time span until the next release.

Kind regards
    Andreas.

Given how many packages will likely have to die as a result of the
GTK2 deprecation (sniff; pour one out for gkrellm, pidgin, ...) there
should probably a set of standardized approachs that maintainers could
select from.

I wonder if one approach might be to upload a replacement package
which has a NEWS file explaining that xzgv has been removed to the
GTK2 deprecation, and suggesting some possible alternatives that users
could choose from.  I do agree it needs to be up to the users, since
there really isn't a single drop-in replacement.  But it seems it
would be nice if there was a way to give users some pointers to
alternatives.

						- Ted

Hi Ted,

Am Tue, Mar 03, 2026 at 09:57:08AM -0500 schrieb Theodore Tso:
packaging into Debian Phototools team on Salsa (to provide an example on
a public place).  There we provide a metapackage versioned

    0.9.2+transition-1

(or something like this) with no real code but just Dependencies

   Recommends: nsxiv | geeqie | eog

This would ensure that xzgv will not be left alone with something
comparable.

I noticed that xzgv source package is featuring debian/gbp.conf.  So I
assume you are using some Git repository somewhere.  If you agree with
the plan in principle it would be nice to keep the packaging history on
that public place as well.  I'd volunteer to import your repository
implement that plan and let you review the result.

The metapackage should close both open bugs BTW.

What do you think?

Kind regards
    Andreas.