Advice needed on ffcall packaging

[Ken Brown]

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