Please consider removing this package as it is a helper library but
nothing depends on it anymore. Upstream is inactive for 8 years.

Le 01/04/2026 à 16:08, Bastian Germann a écrit :

easybind is a dependency required for upgrading jabref to the version 4
and above. I'd keep the package unless we plan to remove jabref.

Emmanuel Bourg

Le 01/04/2026 à 16:19, Emmanuel Bourg a écrit :

The JabRef provides its own Debian package [1], so removing it is worth
considering.

Emmanuel Bourg

[1]
https://github.com/JabRef/jabref/releases/download/v5.15/jabref_5.15_amd64.deb

There is also a snap [1] available that makes it easy to install the
latest versions on either amd64 or arm64.

Introducing more recent versions of JabRef (newer than 3.8.2) to Debian
main would require significant investment in tooling (Gradle) and
packaging a non-trivial list of new library dependencies.

It's not a project I can commit to (until I win the lottery), so unless
someone else is keen on it, I don't expect to see JabRef 5.x or 6.x in
Debian anytime soon.

Regarding requesting RM of jabref 3.8.2 [2], there are a number of
installs according to popcon [3], and it is still functional and
useful despite its age.  I don't have a strong opinion either way, but
perhaps it's in the best interest of Debian users to advertise the
alternative methods of installation in the Debian package itself.

Cheers,
tony

cc: Gregor and Oliver

[1] https://snapcraft.io/install/jabref/debian
[2] https://tracker.debian.org/pkg/jabref
[3] https://qa.debian.org/popcon-graph.php?packages=jabref&show_installed=on&want_legend=on&want_ticks=on&date_fmt=%25Y-%25m&beenhere=1

Le 02/04/2026 à 06:49, tony mancill a écrit :

The popcon is probably mlisleading, because the upstream package has the
same name as the Debian package, so the popcon graph shows both packages
installations.

Emmanuel Bourg

Hey,

my "internal" plan is as follows:

1. Finish JabRef 6.0 - the team is still discussing the local
database backend (postgres vs. sqlite vs. something else - details at
https://github.com/JabRef/jabref/issues/12708)
2. Check if the build of JabRef 6.0 can be done using another build system
(more "compatible" with Debian) [*1], [*2]
3. Create a table of dependencies and their state in debian - meaning
updating https://github.com/JabRef/jabref-koppor/issues/135
4. Work on each item of the table

Regarding 4: Maybe, each packaging can be made as exercise for students so
that they learn about the challenges in packaging

In general, I perceive researchers being "lazy" and not installing software
using Snap / Flatpack / custom .deb files if they are available in the
distribution.What I don't know is if JabRef was unavailable in Debian, if
people use other tools or invest the extra effort to install JabRef from
another source.

Sharing some general roadmap:

- We are thinking of a terminal ui for JabRef (
https://jabref.github.io/GSoC/posts/tui/) - maybe, this can narrow down the
dependencies.
- We do have a CLI tool "jabkit" -
https://github.com/JabRef/jabref/tree/main/jabkit -- currently very rough,
but could be a start for packaging.

HTH

Oliver

[*1] Although JabRef heavily relies on features of the Gradle eco system,
my impression is that these "features" are "only" because of jpackage
generating an installer. JabRef does not use Java's Module System in other
ways (yet).
[*2] I was thinking about bld (https://rife2.com/bld), but that doesn't
seem to be available in Debian 😅

Am Do., 2. Apr. 2026 um 09:47 Uhr schrieb Emmanuel Bourg <ebourg@apache.org

Regarding the package at hand. It will surely be used in JabRef 6.x. JabRef
made a fork: https://github.com/JabRef/EasyBind/releases/tag/v2.3.0 - based
on a fork (https://github.com/tobiasdiez/EasyBind) from the original
EasyBind.

Thus, the package should either be updated - or removed for now and
re-packaged if there is activity on JabRef's debian packaging.

Am Do., 2. Apr. 2026 um 12:57 Uhr schrieb Oliver Kopp <kopp.dev@gmail.com>: