Simon McVittie <s...@debian.org> 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
