Лучше даже, чтобы нельзя было удалять пакет без указания причины.

(В ответ на комментарий №1)
> Лучше даже, чтобы нельзя было удалять пакет без указания причины.
У меня при обновлении Ruby (#187297) для инициаторов заготовлена чудесная причина: "."

$ girar-show 187297@ | grep del | wc -l
20

Разумнее не нагибать мейнтейнеров в духе Microsoft, а фиксировать при удалении номер задания. Тогда будет понятно, кто и зачем удалил. И эту информацию проще всегда получить в адекватном виде.

> Разумнее не нагибать мейнтейнеров в духе Microsoft, а фиксировать при удалении
> номер задания. Тогда будет понятно, кто и зачем удалил. И эту информацию проще
> всегда получить в адекватном виде.

Номер задания и так уже есть, в имени ветки пакета, типа old/$repobranch-task$girartasknumber. Найти кто удалил тоже можно.

Но вот, например, отсюда какую информацию можно получить именно о причине удаления?
http://git.altlinux.org/tasks/archive/done/_152/155997/

(В ответ на комментарий №3)
> > Разумнее не нагибать мейнтейнеров в духе Microsoft, а фиксировать при удалении
> > номер задания. Тогда будет понятно, кто и зачем удалил. И эту информацию проще
> > всегда получить в адекватном виде.
> 
> Номер задания и так уже есть, в имени ветки пакета, типа
> old/$repobranch-task$girartasknumber. Найти кто удалил тоже можно.
> 
> Но вот, например, отсюда какую информацию можно получить именно о причине
> удаления?
> http://git.altlinux.org/tasks/archive/done/_152/155997/
Спросить rt.

(In reply to comment #3)
> > Разумнее не нагибать мейнтейнеров в духе Microsoft, а фиксировать при удалении
> > номер задания. Тогда будет понятно, кто и зачем удалил. И эту информацию проще
> > всегда получить в адекватном виде.
> 
> Номер задания и так уже есть, в имени ветки пакета, типа
> old/$repobranch-task$girartasknumber. Найти кто удалил тоже можно.
> 
> Но вот, например, отсюда какую информацию можно получить именно о причине
> удаления?
> http://git.altlinux.org/tasks/archive/done/_152/155997/

В целом, я поддерживаю сохранение записи о причине. Пока такого нет, некоторые иногда пишут что-то об удалениях в списках рассылки или wiki.

По повода тех python-* пакетов могу только догадываться, что это могло быть удаление из-за невозможности пересобрать некоторые из них, в одном ряду с https://intranet.altlinux.ru/Python3.5#.D0.A3.D0.B4.D0.B0.D0.BB.D0.B5.D0.BD.D0.BE .

(В ответ на комментарий №4)
> (В ответ на комментарий №3)
> > > Разумнее не нагибать мейнтейнеров в духе Microsoft, а фиксировать при удалении
> > > номер задания. Тогда будет понятно, кто и зачем удалил. И эту информацию проще
> > > всегда получить в адекватном виде.
> > 
> > Номер задания и так уже есть, в имени ветки пакета, типа
> > old/$repobranch-task$girartasknumber. Найти кто удалил тоже можно.
> > 
> > Но вот, например, отсюда какую информацию можно получить именно о причине
> > удаления?
> > http://git.altlinux.org/tasks/archive/done/_152/155997/
> Спросить rt.

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

(In reply to comment #0)
> Также можно модифицировать вызов girar task add, чтобы добавить (опциональный
> или обязательный) параметр, следующим образом:
> girar-task add [<task_id> [<before_subtask_id>]] del <package> [<reason>]

Хорошо, но есть ещё girar-build del <package_name>, как поступить с ней?

(В ответ на комментарий №4)
> Спросить rt.

И rt ответит "не помню". Через месяц.
Файл deadpackage в Федоре не раз мне помогал понять что произошло с пакетом.

(In reply to comment #8)
> (В ответ на комментарий №4)
> > Спросить rt.
> 
> И rt ответит "не помню". Через месяц.
> Файл deadpackage в Федоре не раз мне помогал понять что произошло с пакетом.

Обеспечивать выполнение тоже будем как в Федоре - добавление и удаление пакетов только через approve?

> Обеспечивать выполнение тоже будем как в Федоре - добавление и удаление пакетов
> только через approve?

Ну, это лишнее, у нас по идее ментор на join есть.
А заставить людей писать причину удаления пакета вряд ли получится, хотя очень хочется. Но ничто не помешает им ставить ".".

(In reply to comment #7)
> Хорошо, но есть ещё girar-build del <package_name>, как поступить с ней?

Если нет возможности сделать girar-build del <package_name> [<reason>], то можно сделать girar-build delcom <package_name> [<reason>] или girar-build delcom <package_name> <reason> . Вместо "delcom" можно подставить любое другое название по вкусу.

(In reply to comment #10)
> А заставить людей писать причину удаления пакета вряд ли получится, хотя очень
> хочется. Но ничто не помешает им ставить ".".

Помешает, если не давать ставить слишком короткие причины удаления. (меньше четырёх символов)

(В ответ на комментарий №12)
> (In reply to comment #10)
> > А заставить людей писать причину удаления пакета вряд ли получится, хотя очень
> > хочется. Но ничто не помешает им ставить ".".
> 
> Помешает, если не давать ставить слишком короткие причины удаления. (меньше
> четырёх символов)
Сами догадаетесь, куда пошлют при таком закручивании гаек. Вам заняться нечем?

(In reply to comment #11)
> (In reply to comment #7)
> > Хорошо, но есть ещё girar-build del <package_name>, как поступить с ней?
> 
> Если нет возможности сделать girar-build del <package_name> [<reason>], то
> можно сделать girar-build delcom <package_name> [<reason>] или girar-build
> delcom <package_name> <reason> . Вместо "delcom" можно подставить любое другое
> название по вкусу.

А можно:

girar-build del-REASON <package_name>

чтобы не нарушать принципа чётности аргументов.

Правда, по ssh не очень удобно квотить пробелы в аргументе, но можно придумать способ.

(In reply to comment #14)
> А можно:
> 
> girar-build del-REASON <package_name>
> 
> чтобы не нарушать принципа чётности аргументов.
> 
> Правда, по ssh не очень удобно квотить пробелы в аргументе, но можно придумать
> способ.

Если уж ставить так задачу, то можно сделать и так:

girar-build del <package_name> [reason <reason>]

(In reply to comment #15)

> Если уж ставить так задачу, то можно сделать и так:
> 
> girar-build del <package_name> [reason <reason>]

Может быть, сделать одну причину на всё задание?

girar-build  [-m <reason>] del <package_name> ...

Ведь нет смысла помещать в одно задание пакеты, чьи изменения не свзяаны общей причиной.

(In reply to comment #16)
> (In reply to comment #15)
> 
> > Если уж ставить так задачу, то можно сделать и так:
> > 
> > girar-build del <package_name> [reason <reason>]
> 
> Может быть, сделать одну причину на всё задание?
> 
> girar-build [-m <reason>] del <package_name> ...
> 
> Ведь нет смысла помещать в одно задание пакеты, чьи изменения не свзязаны общей причиной.

+1, и это верно не только в случае удаления пакетов

*** Bug 28481 has been marked as a duplicate of this bug. ***

Запишу что сегодня обсуждали. Ещё один возможный вариант хранения - для записи причины удаления создавать тэг с текстом причины удаления аналогично тому, как такой тэг создаётся при сборке пакета, и вешать его на ветку old/$something, создаваемую при удалении пакета. Однако, сейчас при удалении пакетов, собираемых из src-rpm, такая ветка не создаётся. Либо нужно создавать и там такую ветку, либо можно вешать этот тэг куда-то ещё. Может, просто на коммит, из которого происходила последняя сборка?

(В ответ на комментарий №16)
> (In reply to comment #15)
> > Если уж ставить так задачу, то можно сделать и так:
> > girar-build del <package_name> [reason <reason>]
> 
> Может быть, сделать одну причину на всё задание?
> girar-build  [-m <reason>] del <package_name> ...

Поддерживаю.

> Ведь нет смысла помещать в одно задание пакеты, чьи изменения не свзяаны
> общей причиной.

Особенно когда считаешь нужным её указать.

_Заставлять_ указывать я бы не стал по очевидным и местами вышеперечисленным причинам: стоит _помочь_ тем, кто хочет помочь, а не пытаться заставить тех,
кто почему-то в проекте, но не настроен на совместную работу.

PS: Дима, что именно тебя не устроило в этом конкретном предложении imz@?
(ср.: https://lists.altlinux.org/pipermail/devel/2019-February/206963.html)

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

Давайте для начала просто сделаем [-m reason] для build и run.

Да!

(In reply to comment #19)
> Запишу что сегодня обсуждали. Ещё один возможный вариант хранения - для записи
> причины удаления создавать тэг с текстом причины удаления аналогично тому, как
> такой тэг создаётся при сборке пакета, и вешать его на ветку old/$something,
> создаваемую при удалении пакета. Однако, сейчас при удалении пакетов,
> собираемых из src-rpm, такая ветка не создаётся. Либо нужно создавать и там
> такую ветку, либо можно вешать этот тэг куда-то ещё. Может, просто на коммит,
> из которого происходила последняя сборка?

Теперь старая ветка будет переименовываться и в случае, когда пакет был ранее собран из srpm, а не только из gear.

(In reply to comment #22)
> Давайте для начала просто сделаем [-m reason] для build и run.

Готово.

(In reply to comment #25)
> (In reply to comment #22)
> > Давайте для начала просто сделаем [-m reason] для build и run.
> 
> Готово.

К сожалению, в тексте сообщения сейчас не может быть пробелов. :)

(В ответ на комментарий №26)
> К сожалению, в тексте сообщения сейчас не может быть пробелов. :)

"Беда, но не катастрофа" (ц) :-)
Хотя с ними будет, конечно, чуть удобней.

> 2019-Feb-23... :: task #222679 for sisyphus started by ldv:
> 2019-Feb-23... :: message: rebuilt_to_update_subpackage_interdependencies
> #100 build 4.1-alt2 from /gears/d/dosfstools.git fetched at 2019-Feb-23...

Спасибо!

(In reply to comment #1)
> Лучше даже, чтобы нельзя было удалять пакет без указания причины.

girar commit 1ce38b3c411a7701d6a0ea1947cad9226c6de01f:
girar-build, girar-task-run: require a reason for package removals

Закрываем, или ждём, когда кто-нибудь реализует git commit --allow-empty -m "Текст причины"?

(In reply to Dmitry V. Levin from comment #29)
> Закрываем, или ждём, когда кто-нибудь реализует git commit --allow-empty -m
> "Текст причины"?

А зачем пустой коммит? Можно создать orphaned-ветку с единственным коммитом, текст которого описывает причину, которая заодно продублирована, например, в .gear/del.reason

То, что хотя бы в логах есть указание причины - уже хорошо. Но эти логи ещё надо найти. Для архивированных тасков кроме ручного поиска нужного таска в http://git.altlinux.org/tasks/archive/done/ я способов не знаю. И это довольно неудобный интерфейс. Поэтому указание причины прямо в репозитории любым способом было бы заметно удобнее. Поэтому я склоняюсь к варианту "подождём реализации сохранения причины в репозитории любым удобным способом".

(In reply to Aleksei Nikiforov from comment #31)
> То, что хотя бы в логах есть указание причины - уже хорошо. Но эти логи ещё
> надо найти. Для архивированных тасков кроме ручного поиска нужного таска в
> http://git.altlinux.org/tasks/archive/done/ я способов не знаю.

Есть ещё индекс исходных пакетов.
Например, вчера был удалён пакет python-module-pytest_sourceorder,
можно зайти на http://ftp.altlinux.org/pub/distributions/archive/sisyphus/index/src/p/python-module-pytest_sourceorder/ и пойти оттуда по ссылке http://git.altlinux.org/tasks/archive/done/_249/255737/.

(In reply to Aleksei Nikiforov from comment #31)
> Поэтому я склоняюсь к варианту
> "подождём реализации сохранения причины в репозитории любым удобным
> способом".

Я тоже, но на данный момент над реализацией никто не работает.

Просто для истории - у нас на https://beta.packages.altlinux.org/ru/sisyphus/srpms/perl-IO-stringy/ реализовано отображение сообщения для удаляемых пакетов из заданий girar. Возможно, этого будет достаточно для закрытия этой ошибки.

(Ответ для Anton Farygin на комментарий #34)
> Просто для истории - у нас на
> https://beta.packages.altlinux.org/ru/sisyphus/srpms/perl-IO-stringy/
> реализовано отображение сообщения для удаляемых пакетов из заданий girar.
> Возможно, этого будет достаточно для закрытия этой ошибки.

Оно уже сохраняется, и даже можно найти и прочитать, даже без этого сайта, пусть и не особо удобно - найти номер таска, а затем по номеру - сам таск, и там прочитать. Поэтому как автор бага считаю его решённым.