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
Reply to: