Created attachment 21239 [details]
скриншот

Created attachment 21240 [details]
скриншот

Created attachment 21241 [details]
скриншот

Ну и apt после этого неработоспособен.

На худой конец
%_bindir/%name migrate ||:

Изучил в чем причина. Ошибка связана с тем, что в LiveCD образе /var/cache/stplr/db принадлежит root:root, что было не совсем ожидаемо.

Почему это произошло: migrate во время своей работы меняет пользователя с root на stapler-builder и мигрирует (если ее нет, то создает) БД. 
А т.к. во время сборки пакет ставится в fakeroot среду, то смена пользователя работает не совсем корректно.

Чтобы в hasher это не вызывало проблем:
- добавлю в migrate смену владельца на /var/cache/stplr/db, чтобы исправить миграцию;
- если до миграции база отсутствует, то и создаваться она не будет, чтобы подобных проблем не возникало.

Исправлю в ближайшее время.

(Ответ для Maxim Slipenko на комментарий #6)
> /var/cache/stplr/db принадлежит root:root, что было не совсем ожидаемо.
Еще можно упаковать пустую с нужными правами, тогда будет ожидаемо.
Это приемлемее, чем лишние манипуляции с правами.

А почему база вообще создалась с правами root?
Может, исправить запуск %post, чтоб %_bindir/%name migrate не от root делался или вовремя переключался на нужного пользователя?

(Ответ для Maxim Slipenko на комментарий #6)
> - добавлю в migrate смену владельца на /var/cache/stplr/db, чтобы исправить
> миграцию;
Возможно, правильнее это сделать post-триггером в пакете, чтоб срабатывал только при обновлении до исправленной версии.

(Ответ для Sergey V Turchin на комментарий #8)
> А почему база вообще создалась с правами root?

fakeroot, используемый hasher, дает "root" через подмену системных вызовов (через LD_PRELOAD), поэтому setgid и setuid не делает реальную смену пользователя.

Короче говоря, этот C код:

#include <stdio.h>
#include <unistd.h>

int main() {
    printf("uid=%d euid=%d\n", getuid(), geteuid());
    setgid(923);
    setuid(923);
    printf("uid=%d euid=%d\n", getuid(), geteuid());
    FILE *f = fopen("/tmp/fakeroot_test.txt", "w");
    fprintf(f, "foo");
    fclose(f);
    return 0;
}

в системе сделает:

$ sudo ./a
uid=0 euid=0
uid=923 euid=923
$ ls -la /tmp/fakeroot_test.txt
-rw-r--r-- 1 stapler-builder stapler-builder 3 мая  1 19:35 /tmp/fakeroot_test.txt

А в hasher (hsh-shell --rooter):

[root@localhost .in]# /.in/a 
uid=0 euid=0
uid=923 euid=923
[root@localhost .in]# ls -la /tmp/fakeroot_test.txt 
-rw-r--r-- 1 root root 3 May  1 16:37 /tmp/fakeroot_test.txt

В программе на Go ситуация будет немного другая (там подмена через LD_PRELOAD не сработает), но итог такой же -- файл будет под root:root.

Тогда, наверное, не создавать в migrate базу, если её не было и в %triggerin поправить права при обновлении до исправленной версии.

Да, ещё:
* не запускать migrate вообще при установке пакета, а только при обновлении
* упаковать базу при помощи %gost, чтоб удалялась при удалении пакета

Исправлено в 0.1.1-alt1

Всё-таки рекомендую использовать %triggerin , чтоб каждый раз не делать chown при обновлении пакета.

(Ответ для Sergey V Turchin на комментарий #14)
> Всё-таки рекомендую использовать %triggerin , чтоб каждый раз не делать
> chown при обновлении пакета.

Мне не совсем очевидно, как это должно работать.
Если сделать в %triggerin = 0.1.1, то при обновлении 0.0.31 -> 0.2.0 это же не сработает, ведь так?
А если в %triggerin -- %name >= 0.1.1, то это не отличается от %post.

Может быть стоит %triggerun -- %name < 0.1.1, но тогда и migrate должен быть в %triggerun -- %name. 
Но, кажется, при этом подходе у меня не получилось что-то.

(Ответ для Maxim Slipenko на комментарий #15)
> Мне не совсем очевидно, как это должно работать.
В документации по rpm всё есть. Сработает ровно тогда, когда укажете.

Где-то был репозиторий со всеми spec-ами. grep-ните там примеры.