>> Возможно, если на наличие стартового "/" завязана какая-то внешняя логика,
>> ...
> Всё так, но не могли бы вы проверить, как это работает на практике. Дело в том, что сюда путь передаётся уже после readlink -f, то есть абсолютный путь к файлу.

Хм.
$ epm -qf /usr/sbin/slackpkg
$ grep -R usr/sbin/slackpkg /var/log/packages
/var/log/packages/slackpkg-2.82.0-noarch-8:usr/sbin/slackpkg

Но:
$ epm -qf usr/sbin/slackpkg
$ grep -R  /var/log/packages
...

если правильно путаю, выдаст сущую ахинею (все строки всех файлов в /var/log/packages).

>> Кроме того, можно воспользоваться и "/usr/sbin/slackpkg file-search $@"
> Он же ищет по всем пакетам, не только установленным?

Да, по всем пакетам из репозитория, установленным или нет. Ок, если "epm -qf файл" -- это поиск по файлам установленных пакетов, то вариант с slackpkg может подойти только в варианте
/usr/sbin/slackpkg file-search $@ | grep -v "[uninstalled]"

Ещё пара интересных моментов:
epm -i package-file
что должно произойти, если пакет предыдущей версии установлен?

Если выполнить в этой ситуации
installpkg package-name--version_new-arch-build.tgz
пакет будет установлен, в /var/log/packages/package-name-version-arch-build будет записано всё, что полагалось, совпавшие по именам файлы нового пакета заменят файлы старого, в базе пакетного менеджера будет две записи о пакете package-name:
/var/log/packages/package-name-version_old-arch-build
/var/log/packages/package-name-version_new-arch-build
что, вполне объяснимо, но не вполне соответствует действительности с точки зрения содержания ФС после установки.

Если в подобной ситуации нужно обновление, то практичнее использовать для установки вместо "installpkg package-file"
upgradepkg --install-new package-file
поведение: если не установлен, то установить; если установлен, то обновить. Осторожно: upgradepkg проверяет версии НЕ на больше/меньше, а на равно; если версии (включая сборку и тэг) одинаковы, пакет пропускается, если разные -- замена ранее установленного пакета будет произведена, даже если его версия "больше".

ps. slackpkg -- сценарий на bash, там есть что по(д)смотреть.
pps. Вообще говоря, можно рассматривать несколько уровней:
1) pkgtools -- installpkg/upgradepkg/removepkg + поиски по /var/log/packages. Первые два работают только с файлами пакетов; removepkg работает с именами пакетов (полными и родовыми), даже если к ним прицеплен путь и расширение. Об автоматических зависимостях,  сетевых репозиториях, сборке из исходников речи нет. Основной пакетный менеджер дистрибутива.
2) slackpkg -- работает как с локальными файлами (пользуется pkgtools), так и с одним репозиторием (сетевым или локальным). Автоматические зависимости и сборку из исходников не поддерживает. Входит в дистрибутив.
3) slapt-get -- работает как с локальными файлами (пользуется pkgtools), так и с несколькими сетевыми репозиториями. Автоматические зависимости поддерживает, если предоставлены репозиторием. Сборка из исходников -- довеском slapt-src. Не входят в дистрибутив.
4) sbopkg -- сборка из исходников, как правило из slackbuilds.org, актуализация ранее собранного. Автозависимости в зачаточном состоянии (посредством сборочных очередей). Не входит в дистрибутив.
ppps. Если желание пообщаться на тему Slackware применительно к epm (и не только) всё ещё имеется, полагаю уместным переместиться из обсуждения собственно новости куда-то в более профильное место, как варианты:
slackware.su/forum
slackware.ru/forum
unixforum.org/index.php?showforum=19
linuxforum.ru/viewforum.php?id=53
или куда-либо по вашему усмотрению.