This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Advice needed on ffcall packaging


On 2/20/2018 1:41 PM, Yaakov Selkowitz wrote:
On 2018-02-20 09:47, Ken Brown wrote:
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.

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.

NAME=ffcall
...
PKG_NAMES="libffcall0 libffcall-devel"
libffcall0_CONTENTS=...
libffcall_devel_OBSOLETES="ffcall"
libffcall_devel_CONTENTS=...

Thanks! It would never have occurred to me that a package could be obsoleted by one of its subpackages.

Ken


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]