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? _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
