Hi, Am 18.01.2011 um 14:42 schrieb Peter FELECAN:
> "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. 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 _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
