[csw-maintainers] When a shared library needs a data file

[Maciej (Matchek) Blizinski]

I'm working on an update to libmagic, and an interesting issue has
appeared.  The shared library is not enough to use libmagic; a data
file is required too (magic.mgc).  You could argue that it's not the
shared library per se that needs that file, but if you use the
libmagic API, you need to initialize your magic cookie with data, and
you assume that the data is already there.  Here's an example usage:

magic_cookie = magic.open()
magic_cookie.load()
magic_cookie.setflags(magic.MAGIC_MIME)
mime = magic_cookie.file(full_path)

In the packaging context, I would like to ensure that

Current layout:

CSWlibmagic: contains libmagic.so.1 and the magic.mgc file

How to split it up?

Version 1:

CSWlibmagic: Contains magic.mgc, depends on CSWlibmagic1
CSWlibmagic1: Contains libmagic.so.1

CSWlibmagic (data) --> CSWlibmagic1

Advantages: minimal changes to the catalog (new packages, renames, etc)
Disadvantages: Applications need to depend on both libmagic and
libmagic1 in order to achieve working setup.  Dependencies declared
don't match the actual dependencies.

Version 2:

CSWlibmagic: Empty transitional package, depends on CSWlibmagic1
CSWlibmagic1: Contains libmagic.so.1, depends on CSWlibmagic-common
CSWlibmagic-common: Contains magic.mgc

Here, CSWlibmagic1 always pulls in CSWlibmagic-common, and has the
database.  The downside is that there is one package more.

CSWlibmagic (legacy) --> CSWlibmagic1 (shared lib) --> CSWlibmagic-common (data)

Advantages: When CSWlibmagic2 comes along, we'll declare the
dependency CSWlibmagic-common, and CSWlibmagic1 will use the new
shared data.
Disadvantages: Now we have not two, but three packages (until
CSWlibmagic goes away).

Thoughts?