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