Both arcanist and the arc archiver install a binary named 'arc', and so it's not possible to have php5-phabricator and/or php5-arcanist installed at the same time as several other packages such as irssi, amavisd-new and clamav because they depend on archivers/arc. It would be nice if there was perhaps an option to install the arcanist binary under a different name to avoid the conflict. Also, I noticed php5-phabricator depends on perl5.18 while other packages have moved to perl5.20. Would it be possible for 5.20 to be used too, or is it not compatible yet? Running `pkg install php5-phabricator` on my system results in the following output: ``` New packages to be INSTALLED: php5-phabricator: 20150423 perl5.18: 5.18.4_14 php5-arcanist: 20150423 The process will require 70 MiB more space. 18 MiB to be downloaded. Proceed with this action? [y/N]: y Fetching php5-phabricator-20150423.txz: 100% 4 MiB 4.3MB/s 00:01 Fetching perl5.18-5.18.4_14.txz: 100% 13 MiB 7.0MB/s 00:02 Fetching php5-arcanist-20150423.txz: 100% 388 KiB 397.2kB/s 00:01 Checking integrity... done (2 conflicting) Checking integrity... done (0 conflicting) Conflicts with the existing packages have been found. One more solver iteration is needed to resolve them. The following 6 package(s) will be affected (of 0 checked): Installed packages to be REMOVED: irssi-0.8.17_1 amavisd-new-2.10.1_1,1 clamav-0.98.7 arc-5.21p New packages to be INSTALLED: php5-arcanist: 20150423 php5-phabricator: 20150423 The process will require 5 MiB more space. ```
As the route cause is devel/arc I changed the summary. The problematic file is /usr/local/bin/arc, it's been like this ever since the port came into existence/I took over maintainership. The obvious solution would be to rename "arc" to "arcanist" or another unique name. Since this will affect https://wiki.freebsd.org/CodeReview I added bapt and eadler to the Cc list to check if they prefer a different solution (like placing arc in a different/lower priority path).
I am concerned with the approach of renaming devel/arcanist's 'arc'. devel/phabricator looks for a binary called 'arc' for certain actions and I believe a rename might require patching that port. In addition, this makes the use of devel/arcanist to be non-standard among other installs. FWIW, how does debian handle this?
(In reply to Eitan Adler from comment #2) > I am concerned with the approach of renaming devel/arcanist's 'arc'. > devel/phabricator looks for a binary called 'arc' for certain actions and I > believe a rename might require patching that port. In addition, this makes > the use of devel/arcanist to be non-standard among other installs. > > FWIW, how does debian handle this? While I haven't checked how Debian, or other *NIXish systems deal with this. I had a thought I'd like to offer; A simple Case change seems like a simple/easy solution -- Arc vs. arc? Just my 2¢ --Chris
@eadler: Debian had a similar bug report last year. If I interpret it (and the package content) correctly, all they did was make in conflict explicitly to avoid "install files in the same place" errors. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766955
I grepped through the ports collection to see which ports actually depend on archivers/arc at this point. Unconditional dependency: archivers/deco print/apsfilter (COMPRESS dependency) Optional (but default enabled): security/amavisd-new security/clamav security/maia So one option to solve this would be to disable ARC support in those ports by default - something I would be fine with as the last time I used arc consciously myself was probably in 1992. Another option would be to remove the link to arc in /usr/local/bin (this is what arcanist installs) and use /usr/local/lib/php/arcanist/bin/arc instead (not what I would consider comfortable as a user). No matter what we come up with, I would suggest we add explicit CONFLICTS to archivers/arc as well as devel/arcanist.
Does anyone have further suggestions on how to solve this? I would suggest to disable ARC support in default builds in the ports outlined above and mark the two ports as conflicting.
I agree with Michael's latest comment.
Found no package php5-phabricator or php56-phabricator.Devel/arcanist, devel/phabricator and py-phabricator does not confilct with arc.
As both archiveŕs/arc and devel/arcanist contain explicit conflicts excluding each, I'll close this (some of the ports mentioned like ClamAV still build with arc by default, but, well, what can I do).
Just a necro followup to say that this issue is driving me mad too! I was also thinking about disabling ARC by default in clamav, but actually I think this bug should note that disabling clam's ability to scan inside an archive, however esoteric is actually opening up a hole for attackers to exploit-- if you know that FreeBSD users won't notice things inside arc archives, guess which one to use?
(In reply to Chris Rees from comment #10) I run clamav too, but it doesn't really bother me because my mail server runs in its own jail where I don't really run arcanist. Personally I don't really care if clamav supports .arc or not: I don't have arc installed on my desktop systems anyway, and they are pretty rare nowadays...