Advice needed on ffcall packaging
Tue Feb 20 15:48:00 GMT 2018
A few years ago I adopted ffcall (32-bit only) in order to keep it from
disappearing from the distro:
The latest upstream release builds on 64-bit Cygwin, so I'd like to
update the package, and I'd like to find a sensible way of breaking it
up into subpackages. Here are the relevant facts:
1. Cygwin's existing (32-bit) ffcall is really a devel package: It
consists of headers, four (static) libs, and documentation. There are
no subpackages and no shared libs. The static libs are
2. The build of the current release produces the same four static libs,
plus shared versions of the first three, plus a new lib, both static and
shared (libffcall.a and cygffcall-0.dll).
If I were starting from scratch, I would have three packages: ffcall,
libffcall0, and libffcall-devel. ffcall would be source only;
libffcall0 would contain the shared libs *.dll; and libffcall-devel
would contain the headers, the import libs *.dll.a, and the one static
lib for which there is no shared version. I wouldn't ship the other
static libs unless I discover later that they're needed for some reason.
But I'm not starting from scratch, and users of the existing ffcall will
need the new libffcall-devel. I can think of two possibilities for
A) Pretend that I'm starting from scratch, and deal with the fallout.
There probably won't be any, since ffcall is not currently required by
any other package. As far as I know, its only use is that it's a build
requirement for clisp, which I maintain.
B) Make three packages as above, with the source-only package being
called libffcall instead of ffcall. (libffcall is the upstream name
anyway.) I could then make libffcall-devel obsolete ffcall.
For the record, here's what Fedora does: Until a few months ago, there
was only one package, ffcall, which contained everything. At that time
they created two subpackages, ffcall-devel and ffcall-static.
ffcall-devel corresponds to my proposed libffcall-devel; ffcall-static
contains all the static libs; and plain ffcall more-or-less corresponds
to my proposed libffcall0. This doesn't make a lot of sense to me.
Maybe this is much ado about nothing, but I'd appreciate advice.
More information about the Cygwin-apps