33800 2017-08-23 16:29:05 +0300 Добавление и хранение информации о причинах удаления пакета из репозитория 2021-11-19 15:25:40 +0300 1 1 2 Infrastructure Infrastructure girar unspecified all Linux CLOSED FIXED P3 enhancement --- 1 darktemplaralt placeholder evg glebfm icesik imz iv lav ldv mcpain mike rider sem vseleznv cas oldest_to_newest 165374 0 darktemplaralt 2017-08-23 16:29:05 +0300 Полезно было бы хранить (опционально или обязательно) причины об удалениях пакетов из репозитория. Например, возникают ситуации, когда по зависимостям требуются пакеты, которые раньше были в репозитории, но затем были удалёны. Как пример, это можно реализовать храня такую информацию в отдельном коммите в ветке old/$name репозитория, с пустым телом и причиной в тексте коммита (т.е. в коммите сделанном через команду git commit --allow-empty -m "Текст причины"). Также можно модифицировать вызов girar task add, чтобы добавить (опциональный или обязательный) параметр, следующим образом: girar-task add [<task_id> [<before_subtask_id>]] del <package> [<reason>] 165378 1 vseleznv 2017-08-23 18:23:59 +0300 Лучше даже, чтобы нельзя было удалять пакет без указания причины. 165383 2 cas 2017-08-24 07:44:29 +0300 (В ответ на комментарий №1) > Лучше даже, чтобы нельзя было удалять пакет без указания причины. У меня при обновлении Ruby (#187297) для инициаторов заготовлена чудесная причина: "." $ girar-show 187297@ | grep del | wc -l 20 Разумнее не нагибать мейнтейнеров в духе Microsoft, а фиксировать при удалении номер задания. Тогда будет понятно, кто и зачем удалил. И эту информацию проще всегда получить в адекватном виде. 165385 3 darktemplaralt 2017-08-24 10:19:49 +0300 > Разумнее не нагибать мейнтейнеров в духе Microsoft, а фиксировать при удалении > номер задания. Тогда будет понятно, кто и зачем удалил. И эту информацию проще > всегда получить в адекватном виде. Номер задания и так уже есть, в имени ветки пакета, типа old/$repobranch-task$girartasknumber. Найти кто удалил тоже можно. Но вот, например, отсюда какую информацию можно получить именно о причине удаления? http://git.altlinux.org/tasks/archive/done/_152/155997/ 165386 4 cas 2017-08-24 11:30:50 +0300 (В ответ на комментарий №3) > > Разумнее не нагибать мейнтейнеров в духе Microsoft, а фиксировать при удалении > > номер задания. Тогда будет понятно, кто и зачем удалил. И эту информацию проще > > всегда получить в адекватном виде. > > Номер задания и так уже есть, в имени ветки пакета, типа > old/$repobranch-task$girartasknumber. Найти кто удалил тоже можно. > > Но вот, например, отсюда какую информацию можно получить именно о причине > удаления? > http://git.altlinux.org/tasks/archive/done/_152/155997/ Спросить rt. 165387 5 imz 2017-08-24 12:40:25 +0300 (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 . 165392 6 vseleznv 2017-08-24 16:04:55 +0300 (В ответ на комментарий №4) > (В ответ на комментарий №3) > > > Разумнее не нагибать мейнтейнеров в духе Microsoft, а фиксировать при удалении > > > номер задания. Тогда будет понятно, кто и зачем удалил. И эту информацию проще > > > всегда получить в адекватном виде. > > > > Номер задания и так уже есть, в имени ветки пакета, типа > > old/$repobranch-task$girartasknumber. Найти кто удалил тоже можно. > > > > Но вот, например, отсюда какую информацию можно получить именно о причине > > удаления? > > http://git.altlinux.org/tasks/archive/done/_152/155997/ > Спросить rt. Зачем каждый раз спрашивать сопровождающего, когда можно один раз зафиксировать причину, которая будет доступна для всех? Тем более что сопровождающий может не ответить по самым разным причинам. 165397 7 ldv 2017-08-24 19:48:05 +0300 (In reply to comment #0) > Также можно модифицировать вызов girar task add, чтобы добавить (опциональный > или обязательный) параметр, следующим образом: > girar-task add [<task_id> [<before_subtask_id>]] del <package> [<reason>] Хорошо, но есть ещё girar-build del <package_name>, как поступить с ней? 165398 8 sem 2017-08-24 21:11:42 +0300 (В ответ на комментарий №4) > Спросить rt. И rt ответит "не помню". Через месяц. Файл deadpackage в Федоре не раз мне помогал понять что произошло с пакетом. 165399 9 ldv 2017-08-24 21:17:43 +0300 (In reply to comment #8) > (В ответ на комментарий №4) > > Спросить rt. > > И rt ответит "не помню". Через месяц. > Файл deadpackage в Федоре не раз мне помогал понять что произошло с пакетом. Обеспечивать выполнение тоже будем как в Федоре - добавление и удаление пакетов только через approve? 165400 10 sem 2017-08-24 21:25:19 +0300 > Обеспечивать выполнение тоже будем как в Федоре - добавление и удаление пакетов > только через approve? Ну, это лишнее, у нас по идее ментор на join есть. А заставить людей писать причину удаления пакета вряд ли получится, хотя очень хочется. Но ничто не помешает им ставить ".". 165414 11 darktemplaralt 2017-08-25 10:28:29 +0300 (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" можно подставить любое другое название по вкусу. 165416 12 mcpain 2017-08-25 10:53:37 +0300 (In reply to comment #10) > А заставить людей писать причину удаления пакета вряд ли получится, хотя очень > хочется. Но ничто не помешает им ставить ".". Помешает, если не давать ставить слишком короткие причины удаления. (меньше четырёх символов) 165417 13 cas 2017-08-25 11:23:02 +0300 (В ответ на комментарий №12) > (In reply to comment #10) > > А заставить людей писать причину удаления пакета вряд ли получится, хотя очень > > хочется. Но ничто не помешает им ставить ".". > > Помешает, если не давать ставить слишком короткие причины удаления. (меньше > четырёх символов) Сами догадаетесь, куда пошлют при таком закручивании гаек. Вам заняться нечем? 165425 14 imz 2017-08-25 13:21:10 +0300 (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 не очень удобно квотить пробелы в аргументе, но можно придумать способ. 165426 15 darktemplaralt 2017-08-25 13:31:34 +0300 (In reply to comment #14) > А можно: > > girar-build del-REASON <package_name> > > чтобы не нарушать принципа чётности аргументов. > > Правда, по ssh не очень удобно квотить пробелы в аргументе, но можно придумать > способ. Если уж ставить так задачу, то можно сделать и так: girar-build del <package_name> [reason <reason>] 165431 16 imz 2017-08-25 15:02:00 +0300 (In reply to comment #15) > Если уж ставить так задачу, то можно сделать и так: > > girar-build del <package_name> [reason <reason>] Может быть, сделать одну причину на всё задание? girar-build [-m <reason>] del <package_name> ... Ведь нет смысла помещать в одно задание пакеты, чьи изменения не свзяаны общей причиной. 165432 17 ldv 2017-08-25 15:46:27 +0300 (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, и это верно не только в случае удаления пакетов 166716 18 ldv 2017-10-29 04:25:14 +0300 *** Bug 28481 has been marked as a duplicate of this bug. *** 176146 19 darktemplaralt 2018-11-27 19:24:56 +0300 Запишу что сегодня обсуждали. Ещё один возможный вариант хранения - для записи причины удаления создавать тэг с текстом причины удаления аналогично тому, как такой тэг создаётся при сборке пакета, и вешать его на ветку old/$something, создаваемую при удалении пакета. Однако, сейчас при удалении пакетов, собираемых из src-rpm, такая ветка не создаётся. Либо нужно создавать и там такую ветку, либо можно вешать этот тэг куда-то ещё. Может, просто на коммит, из которого происходила последняя сборка? 178852 20 mike 2019-02-22 19:49:45 +0300 (В ответ на комментарий №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) 178853 21 sem 2019-02-22 20:00:12 +0300 Вообще, учитывая, что у нас теперь и rebuild есть, я думаю имеет смысл указывать причину не только в случае удаления пакета, но rebuild, а может и вообще для любого task. 178857 22 ldv 2019-02-23 00:19:50 +0300 Давайте для начала просто сделаем [-m reason] для build и run. 178858 23 mike 2019-02-23 00:38:31 +0300 Да! 178859 24 ldv 2019-02-23 04:59:33 +0300 (In reply to comment #19) > Запишу что сегодня обсуждали. Ещё один возможный вариант хранения - для записи > причины удаления создавать тэг с текстом причины удаления аналогично тому, как > такой тэг создаётся при сборке пакета, и вешать его на ветку old/$something, > создаваемую при удалении пакета. Однако, сейчас при удалении пакетов, > собираемых из src-rpm, такая ветка не создаётся. Либо нужно создавать и там > такую ветку, либо можно вешать этот тэг куда-то ещё. Может, просто на коммит, > из которого происходила последняя сборка? Теперь старая ветка будет переименовываться и в случае, когда пакет был ранее собран из srpm, а не только из gear. 178860 25 ldv 2019-02-23 04:59:56 +0300 (In reply to comment #22) > Давайте для начала просто сделаем [-m reason] для build и run. Готово. 178861 26 ldv 2019-02-23 05:23:20 +0300 (In reply to comment #25) > (In reply to comment #22) > > Давайте для начала просто сделаем [-m reason] для build и run. > > Готово. К сожалению, в тексте сообщения сейчас не может быть пробелов. :) 178862 27 mike 2019-02-23 11:10:05 +0300 (В ответ на комментарий №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... Спасибо! 186692 28 ldv 2019-12-30 03:20:56 +0300 (In reply to comment #1) > Лучше даже, чтобы нельзя было удалять пакет без указания причины. girar commit 1ce38b3c411a7701d6a0ea1947cad9226c6de01f: girar-build, girar-task-run: require a reason for package removals 193436 29 ldv 2020-10-22 18:06:49 +0300 Закрываем, или ждём, когда кто-нибудь реализует git commit --allow-empty -m "Текст причины"? 193440 30 vseleznv 2020-10-22 18:19:10 +0300 (In reply to Dmitry V. Levin from comment #29) > Закрываем, или ждём, когда кто-нибудь реализует git commit --allow-empty -m > "Текст причины"? А зачем пустой коммит? Можно создать orphaned-ветку с единственным коммитом, текст которого описывает причину, которая заодно продублирована, например, в .gear/del.reason 193467 31 darktemplaralt 2020-10-23 10:33:40 +0300 То, что хотя бы в логах есть указание причины - уже хорошо. Но эти логи ещё надо найти. Для архивированных тасков кроме ручного поиска нужного таска в http://git.altlinux.org/tasks/archive/done/ я способов не знаю. И это довольно неудобный интерфейс. Поэтому указание причины прямо в репозитории любым способом было бы заметно удобнее. Поэтому я склоняюсь к варианту "подождём реализации сохранения причины в репозитории любым удобным способом". 193472 32 ldv 2020-10-23 11:11:34 +0300 (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/. 205086 33 ldv 2021-11-19 15:04:10 +0300 (In reply to Aleksei Nikiforov from comment #31) > Поэтому я склоняюсь к варианту > "подождём реализации сохранения причины в репозитории любым удобным > способом". Я тоже, но на данный момент над реализацией никто не работает. 205090 34 rider 2021-11-19 15:11:09 +0300 Просто для истории - у нас на https://beta.packages.altlinux.org/ru/sisyphus/srpms/perl-IO-stringy/ реализовано отображение сообщения для удаляемых пакетов из заданий girar. Возможно, этого будет достаточно для закрытия этой ошибки. 205094 35 darktemplaralt 2021-11-19 15:25:40 +0300 (Ответ для Anton Farygin на комментарий #34) > Просто для истории - у нас на > https://beta.packages.altlinux.org/ru/sisyphus/srpms/perl-IO-stringy/ > реализовано отображение сообщения для удаляемых пакетов из заданий girar. > Возможно, этого будет достаточно для закрытия этой ошибки. Оно уже сохраняется, и даже можно найти и прочитать, даже без этого сайта, пусть и не особо удобно - найти номер таска, а затем по номеру - сам таск, и там прочитать. Поэтому как автор бага считаю его решённым.