[csw-maintainers] When a shared library needs a data file
Peter FELECAN
pfelecan at opencsw.org
Tue Jan 18 14:42:46 CET 2011
"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.
--
Peter
More information about the maintainers
mailing list