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

[Dagobert Michelsen]

Hi,

Am 18.01.2011 um 14:42 schrieb Peter FELECAN:

> "Maciej (Matchek) Blizinski" <maciej at opencsw.org> writes:
> 
>> 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).
> 
> I'm leaning toward 2 as for me the advantages overweight the
> inconveniences. IMO, increasing the number of packages is not an
> obstacle to whatever.

I agree with Peter. And you can also not check dependencies properly
in version 1. Also it is more consistent as the library really *needs*
the file, so there logically should be this dependency as in version 2.


Best regards

  -- Dago