It would be nice to have glabels 4.x in Debian. Could you consider packaging it? Thanks!
Hi, Saw your email and I had a look. glabels the GTK/GNOME version seems to stop at 3.4.1 and if you now go to glabels.org it forwards to: https://github.com/jimevins/glabels-qt and as it suggests the 4.x development of this new major version is QT based only. The choice here is to find out if 3.x will be maintained and do we package as 'glabels-qt' as a separate package entirely. Many questions to be answered. Regards Phil
On Sun, 16 Jan 2022 16:15:43 +0000 Philip Wyett <philip.wyett@kathenas.org> wrote: Yes, I already thought about it. Given its development came a long way now, it might make sense to have it in Debian. There doesn't really seem to be any activity on 3.x anymore. I intend to contact upstream about maintenance and small bugfixes given 3.x will be around for some time. 4.x being a rewrite, I intend to package independently. Most probably as glabels-qt as upstream calls it that way. Cheers, sur5r
glabels-qt is now in Forky. Although it's almost completely a rewrite, the user interface is very similar and gLabels-Qt does a decent job opening the old files. What are current thoughts about handling the transition? Technically gLabels-Qt hasn't made its first 4.0 release yet, so it's premature to have it take over the glabels binary package name. Having them both in Forky and informing users that they ought to migrate seems like a smart choice, but aside from a blurb in the Debian Release Notes I'm afraid there isn't a lot of good precedent for communicating changes like this to users. Maybe a new upload for gLabels 3.0 should be done which adds a NEWS entry, informing users that the package is deprecated and to give gLabels-Qt a try. The Debian archive has the oldlibs section for libraries which are old, but we don't have anything similar for applications. For circumstances like this where there is a logical successor but some manual intervention may be required (which can be done at a user or administrator's leisure), there's not a machine-readable way to express this in a package management frontend. Maybe it's not that common of a need, and using 'oldlibs' would actually be a fine idea if the FTP/archive folks were to concur.
I intend to have at least 1 Debian release with both glabels and glabels-qt so users can migrate easily. Furthermore, glabels will stay as long as glabels-qt is not considered stable by upstream. glabels-qt will also NOT take over the glabels binary package. When (or maybe before) glabels(-gtk) is removed, I might add provides+replaces to glabels-qt. I do not intend to keep empty binary packages around.