Ooops, forgot "[imv]" in the summary

renameutils was first, but I assume that imv is more popular and/or important.

When mono and chicken scheme had a similar conflict over /usr/bin/csc, the same route as OpenBSD was chosen. Even though chicken was first, the executable was packaged as /usr/bin/chicken-csc. This is unfortunate, since Chicken upstream still uses just "csc" in the documentation.

I personally think that the package that first became an official package should "win", but it might make it easier to resolve file name conflicts if the more "important or popular" package "wins". It's also a possibility to just leave the conflict and let users choose.

Ideally, I think someone (TM) should create a register of packages and paths, together with a voting system, which would be the ultimate source of which package "owns" which paths. If such a system were to exist, it could be shared between several Linux distros and UNIX-based operating systems.

The problem of conflicting file paths will not disappear, but become more prominent, as the number of packages grows.

My main interest is to be able to install the programs that are packaged for the distribution I use. And not have to duplicate that effort locally, in AUR or something. I don't care which package that, in this case, installs /usr/bin/imv. But of course all files that are needed to run the programs should be installed *somewhere*.

I could say something about my reasoning around which package should "win", as you say. But since it doesn't really matter to me, I won't. I would be happy if we could even avoid making very hard decision of which package should have priority, which the user can't override in an at least somewhat convenient way.

As a user i just want to install from the available packages and get usable programs. So the main issue for me is that there is a conflict when trying to install them. I want to have both, and not have to choose only either. The current conflicting situation does not give me (enough) choice as a user, I don't agree there.

There is no way currently to install conflicting packages. I tried the pacman.conf NoExtract, which can be used to make a package not install specific files like usr/bin/imv. One could naively think that would allow installing the conflicting packages. But no, the conflict flag is set by maintainer/packager and can mean just any kind of conflict (file conflict or other). So that could not really work.

So a short term solution for this specific case would be that the maintainers of renameutils and imv agree on how to solve this filename conflict, so the conflict flags can be removed.

A longer term solution would be to make it possible to override the conflict flag. This could take a longer time to implement overall. But of course it would help users in the future to work around maintainer choices that they don't like, and get software installed. It feels like this must have been discussed in the Arch community before, do you know?

Then there is the possibility to design a process for arbitration of which packages should be allowed to occupy which paths in the namespace. I guess this might take some time to get implemented as well, if it would eventually. Which such a process in place, I suppose we would get rid of the conflict flag, at least for file name conflicts.

I don't mean to stir anything up here, and I'd just like to get pkgs installed. I'm grateful for all the work you Arch devs put into this os! Also, I could just as well have filed this issue with the renameutils package. It just so happened that renameutils was what I had installed and used for years, when imv appeared on my horizon.

I've also mailed the maintainers of renameutils, noticing them about the issue here.

If your goal is to force packages onto the system and ignore that upstream has chosen to rely on the same filenames as other packages, it is possible: just extract the pkg files with tar, and then just overwrite the conflicting files when extracting the second package.

I don't recommend this, but it IS possible.

The problem with distributions like Arch just renaming files, is that upstream may in some cases rely on certain filenames being used. For example, ViM behaves differently if the executable or symlink is named "evim" instead of "vim".

My goal is to get ready packaged software onto the system using the standard package manager. What you suggest begins to sound like packaging them myself. And something which would have to be redone every time the software/package is updated.

I understand that it may sometimes be the case that renaming filenames causes problems. But the type of problem you mention is not present with imv/renameutils.

There may also be other cases when conflicting packages is more (according to me) acceptable, like the case with gnu-netcat and openbsd-netcat. Here we have two differing implementations of a similar type of software. This also goes for neovim, vim etc.

In the case of imv and renameutils, the situation is different. imv's /usr/bin/imv is also just a script. imv and renameutils are also 2 very different software, which the user very well may want to have installed at the same time. The conflict is more troubling, especially since there is no way around it for me as a user of software officially packaged for the distribution.

I understand and agree with the goal of installing packages without there being filename conflicts. The solution is not obvious, though.

Right now, I think packages having conflicting files is acceptable, and then users can choose which package to install, for non-essential packages. If this was to be considered as an unacceptable situation, I would personally be in favor of resolving this by moving renameutils to AUR.