Bug 33800 - Добавление и хранение информации о причинах удаления пакета из репозитория
Summary: Добавление и хранение информации о причинах удаления пакета из репозитория
Status: CLOSED FIXED
Alias: None
Product: Infrastructure
Classification: Infrastructure
Component: girar (show other bugs)
Version: unspecified
Hardware: all Linux
: P3 enhancement
Assignee: placeholder@altlinux.org
QA Contact: Andrey Cherepanov
URL:
Keywords:
: 28481 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-08-23 16:29 MSK by Aleksei Nikiforov
Modified: 2021-11-19 15:25 MSK (History)
12 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aleksei Nikiforov 2017-08-23 16:29:05 MSK
Полезно было бы хранить (опционально или обязательно) причины об удалениях пакетов из репозитория.
Например, возникают ситуации, когда по зависимостям требуются пакеты, которые раньше были в репозитории, но затем были удалёны.

Как пример, это можно реализовать храня такую информацию в отдельном коммите в ветке old/$name репозитория, с пустым телом и причиной в тексте коммита (т.е. в коммите сделанном через команду git commit --allow-empty -m "Текст причины").

Также можно модифицировать вызов girar task add, чтобы добавить (опциональный или обязательный) параметр, следующим образом:
girar-task add [<task_id> [<before_subtask_id>]] del <package> [<reason>]
Comment 1 Vladimir D. Seleznev 2017-08-23 18:23:59 MSK
Лучше даже, чтобы нельзя было удалять пакет без указания причины.
Comment 2 Andrey Cherepanov 2017-08-24 07:44:29 MSK
(В ответ на комментарий №1)
> Лучше даже, чтобы нельзя было удалять пакет без указания причины.
У меня при обновлении Ruby (#187297) для инициаторов заготовлена чудесная причина: "."

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

Разумнее не нагибать мейнтейнеров в духе Microsoft, а фиксировать при удалении номер задания. Тогда будет понятно, кто и зачем удалил. И эту информацию проще всегда получить в адекватном виде.
Comment 3 Aleksei Nikiforov 2017-08-24 10:19:49 MSK
> Разумнее не нагибать мейнтейнеров в духе Microsoft, а фиксировать при удалении
> номер задания. Тогда будет понятно, кто и зачем удалил. И эту информацию проще
> всегда получить в адекватном виде.

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

Но вот, например, отсюда какую информацию можно получить именно о причине удаления?
http://git.altlinux.org/tasks/archive/done/_152/155997/
Comment 4 Andrey Cherepanov 2017-08-24 11:30:50 MSK
(В ответ на комментарий №3)
> > Разумнее не нагибать мейнтейнеров в духе Microsoft, а фиксировать при удалении
> > номер задания. Тогда будет понятно, кто и зачем удалил. И эту информацию проще
> > всегда получить в адекватном виде.
> 
> Номер задания и так уже есть, в имени ветки пакета, типа
> old/$repobranch-task$girartasknumber. Найти кто удалил тоже можно.
> 
> Но вот, например, отсюда какую информацию можно получить именно о причине
> удаления?
> http://git.altlinux.org/tasks/archive/done/_152/155997/
Спросить rt.
Comment 5 Ivan Zakharyaschev 2017-08-24 12:40:25 MSK
(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 .
Comment 6 Vladimir D. Seleznev 2017-08-24 16:04:55 MSK
(В ответ на комментарий №4)
> (В ответ на комментарий №3)
> > > Разумнее не нагибать мейнтейнеров в духе Microsoft, а фиксировать при удалении
> > > номер задания. Тогда будет понятно, кто и зачем удалил. И эту информацию проще
> > > всегда получить в адекватном виде.
> > 
> > Номер задания и так уже есть, в имени ветки пакета, типа
> > old/$repobranch-task$girartasknumber. Найти кто удалил тоже можно.
> > 
> > Но вот, например, отсюда какую информацию можно получить именно о причине
> > удаления?
> > http://git.altlinux.org/tasks/archive/done/_152/155997/
> Спросить rt.

Зачем каждый раз спрашивать сопровождающего, когда можно один раз зафиксировать причину, которая будет доступна для всех? Тем более что сопровождающий может не ответить по самым разным причинам.
Comment 7 Dmitry V. Levin 2017-08-24 19:48:05 MSK
(In reply to comment #0)
> Также можно модифицировать вызов girar task add, чтобы добавить (опциональный
> или обязательный) параметр, следующим образом:
> girar-task add [<task_id> [<before_subtask_id>]] del <package> [<reason>]

Хорошо, но есть ещё girar-build del <package_name>, как поступить с ней?
Comment 8 Mikhail Efremov 2017-08-24 21:11:42 MSK
(В ответ на комментарий №4)
> Спросить rt.

И rt ответит "не помню". Через месяц.
Файл deadpackage в Федоре не раз мне помогал понять что произошло с пакетом.
Comment 9 Dmitry V. Levin 2017-08-24 21:17:43 MSK
(In reply to comment #8)
> (В ответ на комментарий №4)
> > Спросить rt.
> 
> И rt ответит "не помню". Через месяц.
> Файл deadpackage в Федоре не раз мне помогал понять что произошло с пакетом.

Обеспечивать выполнение тоже будем как в Федоре - добавление и удаление пакетов только через approve?
Comment 10 Mikhail Efremov 2017-08-24 21:25:19 MSK
> Обеспечивать выполнение тоже будем как в Федоре - добавление и удаление пакетов
> только через approve?

Ну, это лишнее, у нас по идее ментор на join есть.
А заставить людей писать причину удаления пакета вряд ли получится, хотя очень хочется. Но ничто не помешает им ставить ".".
Comment 11 Aleksei Nikiforov 2017-08-25 10:28:29 MSK
(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" можно подставить любое другое название по вкусу.
Comment 12 Олег Соловьев 2017-08-25 10:53:37 MSK
(In reply to comment #10)
> А заставить людей писать причину удаления пакета вряд ли получится, хотя очень
> хочется. Но ничто не помешает им ставить ".".

Помешает, если не давать ставить слишком короткие причины удаления. (меньше четырёх символов)
Comment 13 Andrey Cherepanov 2017-08-25 11:23:02 MSK
(В ответ на комментарий №12)
> (In reply to comment #10)
> > А заставить людей писать причину удаления пакета вряд ли получится, хотя очень
> > хочется. Но ничто не помешает им ставить ".".
> 
> Помешает, если не давать ставить слишком короткие причины удаления. (меньше
> четырёх символов)
Сами догадаетесь, куда пошлют при таком закручивании гаек. Вам заняться нечем?
Comment 14 Ivan Zakharyaschev 2017-08-25 13:21:10 MSK
(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 не очень удобно квотить пробелы в аргументе, но можно придумать способ.
Comment 15 Aleksei Nikiforov 2017-08-25 13:31:34 MSK
(In reply to comment #14)
> А можно:
> 
> girar-build del-REASON <package_name>
> 
> чтобы не нарушать принципа чётности аргументов.
> 
> Правда, по ssh не очень удобно квотить пробелы в аргументе, но можно придумать
> способ.

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

girar-build del <package_name> [reason <reason>]
Comment 16 Ivan Zakharyaschev 2017-08-25 15:02:00 MSK
(In reply to comment #15)

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

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

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

Ведь нет смысла помещать в одно задание пакеты, чьи изменения не свзяаны общей причиной.
Comment 17 Dmitry V. Levin 2017-08-25 15:46:27 MSK
(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, и это верно не только в случае удаления пакетов
Comment 18 Dmitry V. Levin 2017-10-29 04:25:14 MSK
*** Bug 28481 has been marked as a duplicate of this bug. ***
Comment 19 Aleksei Nikiforov 2018-11-27 19:24:56 MSK
Запишу что сегодня обсуждали. Ещё один возможный вариант хранения - для записи причины удаления создавать тэг с текстом причины удаления аналогично тому, как такой тэг создаётся при сборке пакета, и вешать его на ветку old/$something, создаваемую при удалении пакета. Однако, сейчас при удалении пакетов, собираемых из src-rpm, такая ветка не создаётся. Либо нужно создавать и там такую ветку, либо можно вешать этот тэг куда-то ещё. Может, просто на коммит, из которого происходила последняя сборка?
Comment 20 Michael Shigorin 2019-02-22 19:49:45 MSK
(В ответ на комментарий №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)
Comment 21 Mikhail Efremov 2019-02-22 20:00:12 MSK
Вообще, учитывая, что у нас теперь и rebuild есть, я думаю имеет смысл указывать причину не только в случае удаления пакета, но rebuild, а может и вообще для любого task.
Comment 22 Dmitry V. Levin 2019-02-23 00:19:50 MSK
Давайте для начала просто сделаем [-m reason] для build и run.
Comment 23 Michael Shigorin 2019-02-23 00:38:31 MSK
Да!
Comment 24 Dmitry V. Levin 2019-02-23 04:59:33 MSK
(In reply to comment #19)
> Запишу что сегодня обсуждали. Ещё один возможный вариант хранения - для записи
> причины удаления создавать тэг с текстом причины удаления аналогично тому, как
> такой тэг создаётся при сборке пакета, и вешать его на ветку old/$something,
> создаваемую при удалении пакета. Однако, сейчас при удалении пакетов,
> собираемых из src-rpm, такая ветка не создаётся. Либо нужно создавать и там
> такую ветку, либо можно вешать этот тэг куда-то ещё. Может, просто на коммит,
> из которого происходила последняя сборка?

Теперь старая ветка будет переименовываться и в случае, когда пакет был ранее собран из srpm, а не только из gear.
Comment 25 Dmitry V. Levin 2019-02-23 04:59:56 MSK
(In reply to comment #22)
> Давайте для начала просто сделаем [-m reason] для build и run.

Готово.
Comment 26 Dmitry V. Levin 2019-02-23 05:23:20 MSK
(In reply to comment #25)
> (In reply to comment #22)
> > Давайте для начала просто сделаем [-m reason] для build и run.
> 
> Готово.

К сожалению, в тексте сообщения сейчас не может быть пробелов. :)
Comment 27 Michael Shigorin 2019-02-23 11:10:05 MSK
(В ответ на комментарий №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...

Спасибо!
Comment 28 Dmitry V. Levin 2019-12-30 03:20:56 MSK
(In reply to comment #1)
> Лучше даже, чтобы нельзя было удалять пакет без указания причины.

girar commit 1ce38b3c411a7701d6a0ea1947cad9226c6de01f:
girar-build, girar-task-run: require a reason for package removals
Comment 29 Dmitry V. Levin 2020-10-22 18:06:49 MSK
Закрываем, или ждём, когда кто-нибудь реализует git commit --allow-empty -m "Текст причины"?
Comment 30 Vladimir D. Seleznev 2020-10-22 18:19:10 MSK
(In reply to Dmitry V. Levin from comment #29)
> Закрываем, или ждём, когда кто-нибудь реализует git commit --allow-empty -m
> "Текст причины"?

А зачем пустой коммит? Можно создать orphaned-ветку с единственным коммитом, текст которого описывает причину, которая заодно продублирована, например, в .gear/del.reason
Comment 31 Aleksei Nikiforov 2020-10-23 10:33:40 MSK
То, что хотя бы в логах есть указание причины - уже хорошо. Но эти логи ещё надо найти. Для архивированных тасков кроме ручного поиска нужного таска в http://git.altlinux.org/tasks/archive/done/ я способов не знаю. И это довольно неудобный интерфейс. Поэтому указание причины прямо в репозитории любым способом было бы заметно удобнее. Поэтому я склоняюсь к варианту "подождём реализации сохранения причины в репозитории любым удобным способом".
Comment 32 Dmitry V. Levin 2020-10-23 11:11:34 MSK
(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/.
Comment 33 Dmitry V. Levin 2021-11-19 15:04:10 MSK
(In reply to Aleksei Nikiforov from comment #31)
> Поэтому я склоняюсь к варианту
> "подождём реализации сохранения причины в репозитории любым удобным
> способом".

Я тоже, но на данный момент над реализацией никто не работает.
Comment 34 Anton Farygin 2021-11-19 15:11:09 MSK
Просто для истории - у нас на https://beta.packages.altlinux.org/ru/sisyphus/srpms/perl-IO-stringy/ реализовано отображение сообщения для удаляемых пакетов из заданий girar. Возможно, этого будет достаточно для закрытия этой ошибки.
Comment 35 Aleksei Nikiforov 2021-11-19 15:25:40 MSK
(Ответ для Anton Farygin на комментарий #34)
> Просто для истории - у нас на
> https://beta.packages.altlinux.org/ru/sisyphus/srpms/perl-IO-stringy/
> реализовано отображение сообщения для удаляемых пакетов из заданий girar.
> Возможно, этого будет достаточно для закрытия этой ошибки.

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