Re: MBF proposal: remaining users of fltk1.1 (vs. fltk1.3).
Simon McVittie writes: > In an ideal world the non-RC mass-bug-filing would have happened at the > earliest point when the FTLK maintainers considered 1.1 to be deprecated, > with bugs escalated to RC when it becomes feasible to consider removing it > altogether. Yeah, I've been sitting on this notion entirely too long; reverse dependencies' maintainers have generally been proactive about migrating (thanks, everyone!), and continued maintenance of 1.1 hasn't been much of a burden. Per that second point, I'm open to carrying 1.1 in full through one more release if necessary, so I'll leave the bugs as non-RC for now. > You probably can't drop the -dev package unless/until you're ready to > drop the shared library, because it would be a RC bug for dependendent > packages to be unbuildable (consider what would happen if there was a > security update to the dependent package during the bullseye cycle). Understood. I was thinking more in terms of dependent software from outside the archive, though that is of course a secondary concern. >> Subject: #PACKAGE#: Please migrate to FLTK 1.3 >> >> #PACKAGE# still builds against FLTK 1.1, for which it is long past >> time for Debian to drop support. Please migrate to 1.3, which is >> generally as simple as adjusting #PACKAGE#'s build dependencies and >> ensuring that it uses UTF-8 rather than a legacy text encoding. (That >> said, please also make sure that you're linking FLTK dynamically, >> e.g. via fltk-config --ldflags rather than fltk-config --ilbs.) > > I think you mean "--libs", not "--ilbs". Yeah, oops. > This is an unusual calling convention and it might be worth mentioning > explicitly that these options don't do what you would expect from their > names. How about replacing that parenthetical remark with a separate paragraph reading Also, please note that fltk-config (in both branches) differs from typical *-config scripts in having --libs yield paths to *static* libraries. If your build has been making use of this syntax, please substitute --ldflags to obtain proper dynamic linkage. (FLTK does not yet offer pkg-config metadata, sorry.) > Tangentially related to this, it would be great if you could get FLTK > upstream to provide pkg-config metadata (.pc file). The fltk-config script > can't be made "Multi-Arch: same" without considerable extra hacking, and > pkg-config is generally preferred by distros. Yeah, I'm well aware of that, but it would need multiple .pc files, and upstream hasn't historically showed much interest in supplying them: https://www.fltk.org/str.php?L2180 However, it looks like they may finally be coming around: https://github.com/fltk/fltk/issues/22 In general, thanks for weighing in! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: MBF proposal: remaining users of fltk1.1 (vs. fltk1.3).
On Sun, 08 Nov 2020 at 21:07:03 -0500, Aaron M. Ucko wrote: > Debian has had two versions of the FLTK GUI toolkit with nearly > identical APIs for over nine years: 1.1 and 1.3. The only breaking > change in the 1.3 series is that it expects text to be in UTF-8 rather > than legacy national encodings, which Debian has generally deprecated > for quite some time; meanwhile, 1.1 is thoroughly dead upstream. I would say it's always a good time to be doing *non-RC* mass bug filing for use of deprecated dependencies, but it might be a bit late in the cycle to be seriously trying to drop FLTK 1.1 at this stage unless you are prepared to be quite aggressive about providing patches, making bugs RC, and if necessary doing NMUs (transition freeze is only 2 months away). In an ideal world the non-RC mass-bug-filing would have happened at the earliest point when the FTLK maintainers considered 1.1 to be deprecated, with bugs escalated to RC when it becomes feasible to consider removing it altogether. > As such, I would like to try to drop 1.1, or at least its development > package, in time for bullseye. You probably can't drop the -dev package unless/until you're ready to drop the shared library, because it would be a RC bug for dependendent packages to be unbuildable (consider what would happen if there was a security update to the dependent package during the bullseye cycle). > Subject: #PACKAGE#: Please migrate to FLTK 1.3 > > #PACKAGE# still builds against FLTK 1.1, for which it is long past > time for Debian to drop support. Please migrate to 1.3, which is > generally as simple as adjusting #PACKAGE#'s build dependencies and > ensuring that it uses UTF-8 rather than a legacy text encoding. (That > said, please also make sure that you're linking FLTK dynamically, > e.g. via fltk-config --ldflags rather than fltk-config --ilbs.) I think you mean "--libs", not "--ilbs". This is an unusual calling convention and it might be worth mentioning explicitly that these options don't do what you would expect from their names. Typically, in an Autotools-style build system, "ldflags" would refer to options like -L/path/to/foo, and "libs" would refer to the libraries, whose position in the command-line is significant (-lfoo or /path/to/foo.a). But it looks as though in FLTK, "fltk-config --ldflags" is the equivalent of "pkg-config --libs foo" or "sdl2-config --libs", while "fltk-config --libs" is something that normally shouldn't be used by Debian packages. Tangentially related to this, it would be great if you could get FLTK upstream to provide pkg-config metadata (.pc file). The fltk-config script can't be made "Multi-Arch: same" without considerable extra hacking, and pkg-config is generally preferred by distros. smcv
