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 <[email protected] >: > Le 02/04/2026 à 06:49, tony mancill a écrit : > > > 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. > > 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 >
