CHMLib is a library to handle CHM files.
It is used by Okular and other applications to show those files.
It hasn't had a release in 11 years.
It is packaged by all major distributions.
A few weeks ago I got annoyed because we need to carry a patch in Okular flathub because the code is not great and it defines it's own int types.
I tried contacting the upstream author, but unsurprisingly after 11 years he doesn't seem to care much and got no answer.
Then i looked saw that various distributions carry different random set of patches, not great.
So I said, OK, maybe we should just fork it, and emailed 14 people listed at repology as package maintainers for CHMLib saying how they would react to KDE forking CHMLib in an effort to do some basic maintenance, i.e. get it to compile without need for patches, make sure all the patches different distributions has are in the same place, etc.
1 packager answered saying "great"
1 packager answered "nah we want to follow upstream" (... which part of upstream is dead did they not understand?)
1 person answered saying "i haven't been packaging for $DISTRO for ages" (makes sense given how old the package is)
1 person answered saying "not a maintainer anymore but i think you should not break API/ABI of CHMLib" (which makes sense, never said that was planned)
And that's it, so only 4 out of 14 answers and only one of them encouraging.
So I'm asking *YOU*, should we push for a fork or I should stop this crazyness and do something more productive?
There's already a somewhat decently maintained fork: https://github.com/sumatrapdfreader/chmlib (last commit August 2019, so better than a decade ago).
ReplyDeleteTry to coordinate with them for a formal new release, enabling Issues on Github, and integrate whatever patches you found in distributions.
If they are unwilling to become the new upstream, fork it and make a proper release.
The problem is that they have thown API compatibility with the original CHMLib out of the window, so no, that codebase isn't useful for anyone that is not themselves.
ReplyDeleteNot a packager myself anymore but here's my 2c: fork away, but give it a different name so that it's possible to install it side-by-side.
ReplyDeleteMy reasoning is that it would be the "stir the least trouble" option: if you don't use the same names binary distros can keep them installed side by side, and source distros like Gentoo don't need to choose one over the other either.
Optionally, keep a shim package that can be installed to make binaries linking to old chmlib to load/build against the new one (chmlib-2?).
Seems reasonable to me, given the situation.
ReplyDeleteI think I agree with Flameeyes but with the added point:
ReplyDeleteFork CHMLib, clean it up, and write up a couple of blog posts about code improvements, security improvements, and basically your thinking as written up in this blog post and provide the shim.
Make these things publicly available and perhaps even as a project outside of the KDE repositories and market them a bit.
"KDE developer picks up maintenance of abandoned CHMLib project"
"Blog series: KDE developer highlights what bugs are fixed by forking CHMLib"
"A couple of code examples of how NewCHMLib and CHMLib-Shim are drop-in replacements"
If there are security problems with CHMLib and the packages are largely unmaintained it might be a useful tactic to offer your repo and the shim as useful solutions to packages that now have security tickets because of the unmaintained CHMLib.
Some of these articles could also be junior jobs for people who work with software, but aren't programmers themselves. hint hint
There's no point in a new name if it's supposed to be a drop-in replacement. Maybe "KDE CHMLib" but not the file names or anything.
ReplyDeleteIf it's a maintenance burden for distributors to touch dozens of packages just to have them use a fork, it's less likely that they actually pick it up.
In the end only Arch, Debian, Fedora, and openSUSE matter. The rest is either a derivative of one of those or irrelevant.
Btw what Samir suggests seems out of proportion for a dying file format.
ReplyDeleteCHM is an obsolete format, just drop support for it by default.
ReplyDeleteWhy can't I see your pull request on GitHub? Looks like you never even tried to submit it.
ReplyDeletehttps://github.com/jedwing/CHMLib/pulls
Hi,
ReplyDeletegood question.
a) drop it like it's hot. The file format I mean. MS dropped it 17 years ago.
b) fork it on github (so it is public), give it basic maintenance and tell packagers about it. If you (as you plan) keep it compatible, packagers will probably pick it up and then you can start integrating the various patches. ... But I probably would not put too much work into it. Or does CHM have a significant user base somewhere?
It might be out of proportion for a dead-ish format like KAMiKAZOW.
ReplyDeleteI did not read the last sentence well enough. Of course dropping CHM is a very valid choice and on reconsideration, I actually recommend just dropping CHM.
Okular is great software and I love using it for reading and annotating PDFs. It even works nicely as a light PDF editor. If maintaining CHMLib takes away from doing cooler things with Okular, then I am all for dropping it.
AFAIKS, CHM is almost dead but, there may be a few e-Books out there which still use the format and, who knows how many “important” CHM formatted documents are stored in various archives.
ReplyDeleteThis Wikipedia page may help to provide a view on the amount of CHM e-Book material currently in circulation – section “File format support”:
-----------------------------------------
Therefore, my twopence worth is:
* Fork it with a new name.
I think it's great that you care about keeping this legacy format readable for future generations. As it is, I still have .chm files lying around that I need to read from time to time. I really appreciate when my modern OS can read them natively. Also, I install Kubuntu on friends' and clients' computers and they need to be able to read everything without exception. If they can't, they just see "Linux" as being inferior. So if it's not too much work, then yes, I would appreciate it if you forked the abandoned project. Really, if you can why not?
ReplyDelete