|Summary:||archivers/gzip: address conflict with archivers/zutils|
|Product:||Ports & Packages||Reporter:||John Hein <jcfyecrayz>|
|Component:||Individual Port(s)||Assignee:||Dmitry Marakasov <amdmi3>|
|Severity:||Affects Some People||CC:||amdmi3, danilo|
Description John Hein 2020-03-02 02:10:18 UTC
Created attachment 212086 [details] [patch] fix gzip & zutils conflict archivers/gzip and archivers/zutils install _some_ of the same files (e.g., bin/zgrep). Installing gzip-1.10... pkg-static: gzip-1.10 conflicts with zutils-1.8 (installs files into the same place). Problematic file: /usr/local/bin/zcat The attached patch addresses this by creating a ZUTILS option in archivers/gzip. If ZUTILS is on, gzip will not install the conflicting files and have a run-time dependency on archivers/zutils. If off, it will install those files and mark archivers/zutils as a conflicting port. This (ZUTILS=on) allows archivers/gzip and archivers/zutils to both be installed. The patch sets ZUTILS off by default, so there should be no change in the default package. If we commit a change such that ZUTILS is on by default, PORTREVISION should be bumped since that would mean a package change to the default package. There are some differences between the zutils version of the conflicting utilities. For instance, the zutils version of zgrep supports -r (recursive grep), but the gzip version does not. For that reason, I personally prefer the zutils version (and so I could see making ZUTILS=on be the default - not to mention, it allows users to install both packages), but that is not an exhaustive comparison. Generally, my impression is that the differences are small. QA testing: - poudriere testport WITH=ZUTILS & WITHOUT=ZUTILS - ok - portlint - ok
Comment 1 Automation User 2020-05-11 21:53:26 UTC
Build info is available at https://gitlab.com/swills/freebsd-ports/pipelines/144532319
Comment 2 Dmitry Marakasov 2021-02-18 21:02:08 UTC
Should we really complicate this by adding a dependency? IMO just the utils should be made optional.
Comment 3 John Hein 2021-02-19 16:42:20 UTC
Created attachment 222643 [details] [patch] fix gzip & zutils conflict [v2] (In reply to Dmitry Marakasov from comment #2) Sure, we could remove the dependency. I like that better. v2 of the patch is attached. It changes the sense of what the ZUTILS option means. Now it means: install gzip's own flavors or zcat, zdiff, zgrep, etc. Since this conflicts with archivers/zutils, his option now defaults to off for v2. Therefore, this will need a PORTREVISION bump. People will have to install zutils if they want a zcat/zdiff/zgrep/etc. from ports, or just use the versions in base FreeBSD. QA: - poudriere: ok - portlint: ok
Comment 4 Dmitry Marakasov 2021-02-19 21:19:48 UTC
I'd prefer to leave the option enabled by default to provide package contents as intended by upstream and expected by users and consumers (haven't checked, but ports which depend on gzip (xarchiver, deltup) may depend on the utils as well). People who need complex setup such as coexisting gzip and zutils may still build it from ports with option disabled. Would it be OK? Other solutions would be overcomplicated IMO (such as moving utils into separate port or introducing flavors).
Comment 5 John Hein 2021-02-21 15:21:19 UTC
(In reply to Dmitry Marakasov from comment #4) I understand your reasoning. But the zutils in archivers/gzip just aren't as good as those in archivers/zutils in many ways (mentioned in the original post here). I did a check in the ports tree for ports that depend on archivers/gzip: ./sysutils/deltup/Makefile ./archivers/xarchiver/Makefile They don't use the zutils at all. For a wider picture, I checked and didn't see any ports that depend on archives/zutils. The versions in /usr/bin are available (and also better) as well. I haven't done an exhaustive comparison, so I may be missing some reason to use the gzip flavor of zutils. But I've used both in day to day operations, and my general impression is that the gzip ones aren't as good. Counterpoints welcome. So currently I vote we use a default of "off". We can always flip that back the other way if need be. I didn't find any critical need for the "on" case.