(Ответ для viy на комментарий #0)
> Если явно указывать --number=N (и, возможно, не дефолтный путь к hasher dir)
> то не отрабатывет chown <user> для полученных пакетов в SRPMS.hasher

Вы уверены, что вся разница не в том, что при перемещении из чрута
* owner сохраняется если chroot и repo на одной файловой системе
* owner не сохраняется если chroot и repo на разных файловых системах
?

(Ответ для Gleb F-Malinovskiy на комментарий #1)
> (Ответ для viy на комментарий #0)
> > Если явно указывать --number=N (и, возможно, не дефолтный путь к hasher dir)
> > то не отрабатывет chown <user> для полученных пакетов в SRPMS.hasher
> 
> Вы уверены, что вся разница не в том, что при перемещении из чрута
> * owner сохраняется если chroot и repo на одной файловой системе
> * owner не сохраняется если chroot и repo на разных файловых системах
> ?

возможно. похоже. для --number=N у меня и chroot и repo в $TMPDIR,
тогда как без --number= у меня repo через симлинк в другой файловой системе.

соответственно, без --number= я могу подписывать пакеты сразу,
а с --number= приходится делать sudo chown igor *.src.rpm.
Хотелось бы, чтобы chown igor_bN -> igor делал hasher автоматически.

(In reply to viy from comment #2)
> возможно. похоже. для --number=N у меня и chroot и repo в $TMPDIR,
> тогда как без --number= у меня repo через симлинк в другой файловой системе.
> 
> соответственно, без --number= я могу подписывать пакеты сразу,
> а с --number= приходится делать sudo chown igor *.src.rpm.
> Хотелось бы, чтобы chown igor_bN -> igor делал hasher автоматически.

Мне кажется, что вам нужно запускать скрипт наподобие
http://git.altlinux.org/people/ldv/packages/?p=girar.git;a=blob;f=ga/scripts/ga-x-repo-copyself
на все "чужие" файлы.

(Ответ для Dmitry V. Levin на комментарий #3)
> > а с --number= приходится делать sudo chown igor *.src.rpm.
> > Хотелось бы, чтобы chown igor_bN -> igor делал hasher автоматически.
> 
> Мне кажется, что вам нужно запускать скрипт наподобие
> http://git.altlinux.org/people/ldv/packages/?p=girar.git;a=blob;f=ga/scripts/
> ga-x-repo-copyself
> на все "чужие" файлы.

Не совсем понятно. sudo chown igor *.src.rpm мне хватает,
если я буду запускать что-либо наподобие ga-x-repo-copyself,
проблема останется - по умолчанию файлы "чужие",
чтобы их сделать "своими", нужно руками запустить скрипт,
не важно, sudo chown igor *.src.rpm или ga-x-repo-copyself.

нельзя ли копирование из chroot в repo вызывать в hasher от основного пользователя? возможно, как опция?

(Ответ для viy на комментарий #4)
> (Ответ для Dmitry V. Levin на комментарий #3)
> > > а с --number= приходится делать sudo chown igor *.src.rpm.
> > > Хотелось бы, чтобы chown igor_bN -> igor делал hasher автоматически.
> > 
> > Мне кажется, что вам нужно запускать скрипт наподобие
> > http://git.altlinux.org/people/ldv/packages/?p=girar.git;a=blob;f=ga/scripts/
> > ga-x-repo-copyself
> > на все "чужие" файлы.
> 
> Не совсем понятно. sudo chown igor *.src.rpm мне хватает,
> если я буду запускать что-либо наподобие ga-x-repo-copyself,
> проблема останется - по умолчанию файлы "чужие",
> чтобы их сделать "своими", нужно руками запустить скрипт,
> не важно, sudo chown igor *.src.rpm или ga-x-repo-copyself.

Ну ведь лучше же copyself, чем sudo.  Возможно, вам будет удобнее просто всегда делать repo на другой файловой системе чтобы избежать этого эффекта совсем.

> нельзя ли копирование из chroot в repo вызывать в hasher от основного
> пользователя? возможно, как опция?

Оно и вызывается от основного пользователя.  Файлы, которыйе принадлежат саттелиту просто перемещаются по файловой системе.  Да, их можно было бы всегда копировать чтобы права поменялись, но тогда мы добавим лишние действия и увеличим нагрузку на файловую систему.  Чаще всего эти права не очень важны.

(In reply to viy from comment #4)
> (Ответ для Dmitry V. Levin на комментарий #3)
> > > а с --number= приходится делать sudo chown igor *.src.rpm.
> > > Хотелось бы, чтобы chown igor_bN -> igor делал hasher автоматически.
> > 
> > Мне кажется, что вам нужно запускать скрипт наподобие
> > http://git.altlinux.org/people/ldv/packages/?p=girar.git;a=blob;f=ga/scripts/
> > ga-x-repo-copyself
> > на все "чужие" файлы.
> 
> Не совсем понятно. sudo chown igor *.src.rpm мне хватает,
> если я буду запускать что-либо наподобие ga-x-repo-copyself,
> проблема останется - по умолчанию файлы "чужие",
> чтобы их сделать "своими", нужно руками запустить скрипт,
> не важно, sudo chown igor *.src.rpm или ga-x-repo-copyself.
> 
> нельзя ли копирование из chroot в repo вызывать в hasher от основного
> пользователя? возможно, как опция?

hasher делает mv.  В тех случаях, когда этот mv оказывается в пределах одной файловой системы, mv делает rename, в противном случае это copy.

Если вам всегда нужно copy, сделайте, пожалуйста, этот copy самостоятельно.

(Ответ для Dmitry V. Levin на комментарий #6)
> Если вам всегда нужно copy, сделайте, пожалуйста, этот copy самостоятельно.

текущее поведение удобно пользователям gear, менее удобно тем, кто заливает srpm, но не критично, обходится лишней командой.

Разработчики сложных систем напарываются на эту фичу и объезжают ее скриптом.
к примеру, в girar, как понимаю, столкнулись когда то с этой проблемой, объехали ее с помощью доп. скрипта ga-x-repo-copyself и забыли.

Я сам когда-то годы назад прописал в ~/.bashrc при старте создание симлинка из $TMP/hasher/repo в каталог в ~, и все работало. Но последнее время стал активно пользоваться параллельным запуском в $TMP/hasherN, где проблема вылезла опять,
я подумал сначала, что это регрессия в hasher. Спасибо за разъяснение.

Это выглядит, как плохое usability. Поведение по умолчанию удобно не всем.

Я готов добавить опцию командной строки и переменную config для переключения
поведения у тех, кому это нужно.
Будет ли в таком случае мой патч принят?

(In reply to viy from comment #7)
> (Ответ для Dmitry V. Levin на комментарий #6)
> > Если вам всегда нужно copy, сделайте, пожалуйста, этот copy самостоятельно.
> 
> текущее поведение удобно пользователям gear, менее удобно тем, кто заливает
> srpm, но не критично, обходится лишней командой.
> 
> Разработчики сложных систем напарываются на эту фичу и объезжают ее скриптом.
> к примеру, в girar, как понимаю, столкнулись когда то с этой проблемой,
> объехали ее с помощью доп. скрипта ga-x-repo-copyself и забыли.

Нет, ga-x-repo-copyself используется для того, чтобы передать права владения файлами (всего репозитория) от одного пользователя к другому, к hasher это никакого отношения не имеет.  Подобная задача возникает время от времени, поэтому я привёл ссылку на уже существующий инструмент.

> Я сам когда-то годы назад прописал в ~/.bashrc при старте создание симлинка
> из $TMP/hasher/repo в каталог в ~, и все работало. Но последнее время стал
> активно пользоваться параллельным запуском в $TMP/hasherN, где проблема
> вылезла опять,
> я подумал сначала, что это регрессия в hasher. Спасибо за разъяснение.
> 
> Это выглядит, как плохое usability. Поведение по умолчанию удобно не всем.
> 
> Я готов добавить опцию командной строки и переменную config для переключения
> поведения у тех, кому это нужно.
> Будет ли в таком случае мой патч принят?

Патч на mv?  Думаю, что апстрим откажет с аргументацией: если вам нужен cp, то вызывайте cp.  В hasher нужен mv.  Если вам действительно по какой-то загадочной причине нужно передавать владение файлами, которые изготовил hasher, от одного пользователя другому, то почему этот механизм нужно встраивать именно в hasher?  Объясните, я не понимаю.

(Ответ для Dmitry V. Levin на комментарий #8)
> встраивать именно в hasher?  Объясните, я не понимаю.

Удобство. 
пример моего workflow, чиню srpm пакеты. 
$ rpm -i /path/to/srpm
$ vim *.spec
$ hashertarbuild -bs *.spec
Written ~/RPM/SRPMS/name-version.tar
hsh $TMP/hasher1 <options> ~/RPM/SRPMS/name-version.tar
...
hasher создал из ~/RPM/SRPMS/name-version.tar
 $TMP/hasher1/repo/SRPMS.hasher/name-version.srpm
заливать в Сизиф $TMP/hasher1/repo/SRPMS.hasher/name-version.srpm
сразу не могу, файл не имеет прав на запись.
rpm --resign не проходит.
меняю sudo chown igor $TMP/hasher1/repo/SRPMS.hasher/*
заливаю girar-build-srpm $TMP/hasher1/repo/SRPMS.hasher/*

Хотелось бы упросить workflow.
возможно, альтернативно было не менять пользователя, а выдавать на src.rpm права 
664? это менее радикально, а для моих целей тоже подойдет - я себя раз впишу в группы пользователей user_bN.

(In reply to viy from comment #9)
> (Ответ для Dmitry V. Levin на комментарий #8)
> > встраивать именно в hasher?  Объясните, я не понимаю.
> 
> Удобство. 
> пример моего workflow, чиню srpm пакеты. 
> $ rpm -i /path/to/srpm
> $ vim *.spec
> $ hashertarbuild -bs *.spec
> Written ~/RPM/SRPMS/name-version.tar
> hsh $TMP/hasher1 <options> ~/RPM/SRPMS/name-version.tar
> ...
> hasher создал из ~/RPM/SRPMS/name-version.tar
>  $TMP/hasher1/repo/SRPMS.hasher/name-version.srpm
> заливать в Сизиф $TMP/hasher1/repo/SRPMS.hasher/name-version.srpm
> сразу не могу, файл не имеет прав на запись.
> rpm --resign не проходит.
> меняю sudo chown igor $TMP/hasher1/repo/SRPMS.hasher/*
> заливаю girar-build-srpm $TMP/hasher1/repo/SRPMS.hasher/*
> 
> Хотелось бы упросить workflow.
> возможно, альтернативно было не менять пользователя, а выдавать на src.rpm
> права 
> 664? это менее радикально, а для моих целей тоже подойдет - я себя раз впишу
> в группы пользователей user_bN.

Спасибо, что подтвердили моё предположение.
Оставьте, пожалуйста, hasher в покое.

Доработайте или напишите обёртку для rpm --resign, который всегда открывает файл на запись, даже когда не пишет в него.