А при чём тут 2016.1?
Там был например rpm5, а здесь rpm4.
Тоже по другому.
А если серьёзно, это один из стандартных каталогов kde5, 
после перехода на rpm4.
Путь стандартный.
Но только, например у Neon, это путь

/usr/lib/x86_64-linux-gnu/libexec/

У нас, или например у ОМ путь

/usr/lib64/libexec/

Ну а если взять Федору или Магеиа, у них путь

/usr/libexec/

Так собирает сборочная.
Будешь делать, чтобы собирало как у Федору и Магеиа?

Да мне все равно, как, по-моему, путь, как у нас нелогичен. Либо %dir /usr/lib64/libexec должно принадлежать какому-то пакету, какому - не ясно.

Каталог принадлежит тем пакетам, в которых есть файлы по данному пути, очевидно.
Может раньше надо было все %dir прописывать, но довольно давно уже это не требуется.

(In reply to Grigorev Andrey from comment #3)
> Каталог принадлежит тем пакетам, в которых есть файлы по данному пути,
> очевидно.
> Может раньше надо было все %dir прописывать, но довольно давно уже это не
> требуется.

Нет, каталог этот в установленной системе никому не принадлежит. Ты путаешь сборку пакета и установленный пакет.

Например, если в спеке прописать:
/usr/share/foo
то пакеты будет принадлежать и сам каталог /usr/share/foo , и что внутри него.
А если прописать так:
/usr/share/foo/dir1
/usr/share/foo/dir2
то после установлки пакета окажется, что dir1 и dir2 вместе с файлами внутри них принадлежат пакету, а вот /usr/share/foo никому не принадлежит.

Проверил. После удаления пакета с файлом каталоги остаются в системе.
Баг rpm похоже. Стоило бы всё же присваивать подкаталоги пакету хотя бы при установке каталогов, которые до того не существовали.

(In reply to Grigorev Andrey from comment #5)
> Проверил. После удаления пакета с файлом каталоги остаются в системе.
> Баг rpm похоже. Стоило бы всё же присваивать подкаталоги пакету хотя бы при
> установке каталогов, которые до того не существовали.

Это фича. Один файл или директория должен принадлежать только одному пакету в штатном случае. В системе из коробки вообще не должно быть бесхозных каталогов (а они етсь). Если он никому не принадлежит, то и не удаляется, что логично. Рандомному пакету каталог принадлежать не должен. Существует %dir.

(In reply to Mikhail Novosyolov from comment #6)
> (In reply to Grigorev Andrey from comment #5)
> > Проверил. После удаления пакета с файлом каталоги остаются в системе.
> > Баг rpm похоже. Стоило бы всё же присваивать подкаталоги пакету хотя бы при
> > установке каталогов, которые до того не существовали.
> 
> Это фича. Один файл или директория должен принадлежать только одному пакету
> в штатном случае. В системе из коробки вообще не должно быть бесхозных
> каталогов (а они етсь). Если он никому не принадлежит, то и не удаляется,
> что логично. Рандомному пакету каталог принадлежать не должен. Существует
> %dir.

Проверил и на rpm5. То же самое. Каталоги выживают после удаления пакета.
Собственно, сохранение каталогов занимает мало места.
Однако, если по данному пути понадобится при дальнейшем использовании установить симлинк, по опыту получится ошибка установки пакета.

Рассмотрим три сторонних пакета:
А. Пакету принадлежит каталог, не существующий в основном репозитории.
Б. Пакету принадлежит файл в каталоге, но не принадлежит каталог.
С. Пакету принадлежит симлинк по пути каталога.

Итак, существует пакет, которому принадлежит каталог. Пусть к этому пакету нет доступа.
Тогда при установке и удалении Б последующая установка С приведёт к ошибке.
Очевидно, что для избегания такой ошибки требуется присваивать каталоги пакетам всегда.
Очевидно также, что стоит это делать автоматически.

Коталог можно создать/удалить через постскрипты. Не очень ясно, зачем, но случаи бывают разные.
Но тут он уже участвует в %files. Досадно.

(In reply to Grigorev Andrey from comment #7)

> Проверил и на rpm5. То же самое. Каталоги выживают после удаления пакета.
> Собственно, сохранение каталогов занимает мало места.
> Однако, если по данному пути понадобится при дальнейшем использовании
> установить симлинк, по опыту получится ошибка установки пакета.
> 
> Рассмотрим три сторонних пакета:
> А. Пакету принадлежит каталог, не существующий в основном репозитории.
> Б. Пакету принадлежит файл в каталоге, но не принадлежит каталог.
> С. Пакету принадлежит симлинк по пути каталога.
> 
> Итак, существует пакет, которому принадлежит каталог. Пусть к этому пакету
> нет доступа.
> Тогда при установке и удалении Б последующая установка С приведёт к ошибке.
> Очевидно, что для избегания такой ошибки требуется присваивать каталоги
> пакетам всегда.
> Очевидно также, что стоит это делать автоматически.

Что предлагаешь? Знаешь как такое можно исправить?
Можешь мне подсказать, и я сделаю, или сам сделай.
Но проще мне. У тебя других задач хватает.

(In reply to VictorR2007 from comment #9)

> Что предлагаешь? Знаешь как такое можно исправить?
> Можешь мне подсказать, и я сделаю, или сам сделай.
> Но проще мне. У тебя других задач хватает.

Мне пока три варианта на ум пришло:

1. Присваивать пакету те каталоги на этапе установки пакета, которые в системе никому не присвоены. Тогда вопрос к процессу установки пакета. Минус - между системами принадлежность каталогов станет более неоднозначна, так как тот же набор установленных пакетов даст другую принадлежность каталога.
Вариант требует развития, кстати. При удалении пакета по необходимости надо переприсваивать каталог другому пакету, файлы которого используют каталог, либо удалять при отсутствии такого пакета.

2. Присваивать все каталоги пакету вообще. Тогда вопрос к процессу сборки пакета.

3. Отказаться от присваивания каталогов пакету. Считать только файлы и каталоги с вручную выставленными правами, а точнее, эти самые права. Соответственно, пустые никому не принадлежащие каталоги считать сиротами.

Как это реализовать, я не знаю. Скорее всего лучше писать в апстрим. Вполне вероятно, что вопрос уже поднимался, и может даже есть более изящный вариант, чем предложенные выше.

Но даже если правка напишется, до нас она не скоро дойдёт. Конкретно данный баг на вид не слишком важен. Подумаешь, останется в системе путь /usr/lib64/libexec при удалении plasma5-baloo. Много ли вообще таких путей, подкаталоги каторых ни одному пакету не принадлежат? Скорее всего да. Чем конкретно этот случай лучше остальных?
Стоит ли рассматривать этот случай отдельно от остальных?
Можно скриптом откопать все неприсвоенные каталоги в дистрибутиве. А нужно ли, если всё равно хочется поменять автоматику?

Created attachment 5506 [details]
Стандартный каталог

(In reply to Grigorev Andrey from comment #10)
> Подумаешь, останется в системе путь
> /usr/lib64/libexec при удалении plasma5-baloo. Много ли вообще таких путей,
> подкаталоги каторых ни одному пакету не принадлежат?
Он и останется. С чего вы вообще взяли, что он только для plasma5-baloo.
Это стандартный каталог для kde5. С вложенными каталогами, куда устанавливают библиотеки и KDE Frameworks, и Plasma5 и Applications.
Приложил картинку с раскрытием одного из вложенных каталогов, у которого ещё есть вложенные папки.

Немного в дополнение к предыдущему моему сообщению.
Если посмотреть в пакет kde5-macros
 https://abf.rosalinux.ru/import/kde5-macros/blob/rosa2021.1/kde5.macros
то четвёртая сверху строка

%_kde5_libexecdir %{_kde5_libdir}/libexec

где

%_kde5_libdir %{_kde5_prefix}/%{_lib}

где

%_kde5_prefix %{_prefix}

так что решим с этой ошибкой?

(In reply to Vladimir Potapov from comment #13)
> так что решим с этой ошибкой?

Да нет никакой проблемы.