в girar проверяется, (в gb-task-repo-vercheck?) чтобы поступивший пакет был не моложе уже имеющихся в бранчах пакетов. Так как autoimports.altlinux.org скоро станет публичным расширением Сизифа, прошу добавить в эту проверку и пакеты из autoimports. src.list для пакетов из autoimports доступен по адресу: http://autoimports.altlinux.org/pub/ALTLinux/autoimports/Sisyphus/files/list/src.list
Проблема актуальна: люди уже начинают интересоваться пакетами из autoimports, а раз эти пакеты уже могут стоять у пользователей, то нужно проверять, что пакеты, заливаемые в Сизиф, вытесняют пакеты из autoimports.
Прежде чем пакеты из autoimports начнут влиять на правила приема пакетов в Сизиф и бранчи, надо зафиксировать правила, по которым пакеты попадают в autoimports. Иначе получается, что на пакеты в Сизиф и бранчи накладываются достаточно произвольные ограничения, вплоть до невозможности отправить пакет в бранч, поскольку, с одной стороны, он не должен быть свежее сизифного, и, с другой стороны, он должен быть свежее импортированного.
(В ответ на комментарий №2) > надо зафиксировать правила, по которым пакеты попадают в autoimports. Сейчас бранчей в autoimports нет; таким образом, на пакеты в бранчах они не влияют. В момент форка p7 из Сизифа я хочу сделать аналогичный форк и в autoimports, получив, таким образом, autoimports/p7. Тогда и для пакетов в p7/branch необходимо будет проверять, что они старше, чем пакеты в autoimports/p7. Ограничений же, чтобы пакет в branch был моложе пакета в autoimports/Sisyphus, лучше не накладывать. С другой стороны, это не слишком сильное ограничение: раз пакет в autoimports, то его нет в настоящем сизифе и его можно смело туда залить.
Т.е. избыточных ограничений лучше не накладывать - для этого для проверки по версиям снизу использовать смерженный список пакетов, Sisyphus/classic+Sisyphus/autoimports, а для проверки в бранчах по версиям сверху использовать чистый список пакетов Sisyphus/classic. Также, удаление пакетов из Sisyphus/autoimports будет проводиться по крону раз в сутки, поэтому нормально, что src.list для пакетов из autoimports может содержать names пакетов, которые уже залиты в сизиф. Поэтому мерж src.list из autoimports и из Sisyphus/classic надо делать аккуратно.
Проблема по прежнему актуальна, в Сизиф заливаются пакеты с релизом меньше чем в autoimports (последний пример perl-Devel-Autoflush) что может создавать проблемы с обновлением из Сизифа.
(В ответ на комментарий №5) > в Сизиф заливаются пакеты с релизом меньше чем в autoimports Я бы сказал наоборот, в autoimports заливаются пакеты с заведомо большим релизом, чем нужно.
Так меньше alt1_* не получится, т.к. alt0_* не сбэкпортится при надобности.
(В ответ на комментарий №7) > Так меньше alt1_* не получится, т.к. alt0_* не сбэкпортится при надобности. Нужно получать такие, чтоб сбэкпортился.
Может, пока суть да дело, хотябы предупреждение в лог сборки выдавать ? А то, бывает, пост фактум узнаёшь, что пакет-то уже был в autoimports.
Проблема по-прежнему актуальна: python-module-apipkg
Подтверждаю актуальность, пакет eureka: https://packages.altlinux.org/ru/sisyphus/srpms/eureka
2viy я считаю не очень хорошим подходом рассылать спам про то, что в вашем стороннем компоненте пакет убежал вперёд из-за недоразвитости робота и призывать проголосовать за этот "баг". The RPM package perl-Search-Xapian-1.2.25.2-alt1.src.rpm you uploaded to Sisyphus is not greater than the RPM package perl-Search-Xapian-1.2.25.2-alt5_7.src.rpm Please, visit https://bugzilla.altlinux.org/show_bug.cgi?id=27419 and vote for the bug. https://src.fedoraproject.org/rpms/perl-Search-Xapian/blob/master/f/perl-Search-Xapian.spec : %changelog * Tue Jul 28 2020 Fedora Release Engineering <releng@fedoraproject.org> - 1.2.25.2-7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Tue Jun 23 2020 Jitka Plesnikova <jplesnik@redhat.com> - 1.2.25.2-6 - Perl 5.32 rebuild * Thu Jan 30 2020 Fedora Release Engineering <releng@fedoraproject.org> - 1.2.25.2-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild * Fri Jul 26 2019 Fedora Release Engineering <releng@fedoraproject.org> - 1.2.25.2-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild * Fri May 31 2019 Jitka Plesnikova <jplesnik@redhat.com> - 1.2.25.2-3 - Perl 5.30 rebuild * Sat Feb 02 2019 Fedora Release Engineering <releng@fedoraproject.org> - 1.2.25.2-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild * Sun Sep 23 2018 Emmanuel Seyman <emmanuel@seyman.fr> - 1.2.25.2-1 - Update to 1.2.25.2 Очень мило, что ваш робот сделал эту работу и упаковал столь важные изменения, но я отказываюсь учитывать циклы пересборки в fedora в своей работе в сизифе. Я вполне уверен, что эти релизы бессмысленны для сизифа. Более того, вы и сами поднимаете релиз: %changelog * Thu Oct 01 2020 Cronbuild Service <cronbuild@altlinux.org> 1.2.25.2-alt5_7 - rebuild to get rid of unmets * Thu Oct 01 2020 Igor Vlasenko <viy@altlinux.ru> 1.2.25.2-alt4_7 - rebuild with perl 5.30 * Tue Jan 29 2019 Cronbuild Service <cronbuild@altlinux.org> 1.2.25.2-alt3_1 - rebuild to get rid of unmets * Tue Jan 29 2019 Cronbuild Service <cronbuild@altlinux.org> 1.2.25.2-alt2_1 - rebuild to get rid of unmets (Кстати, предлагаю упростить запись и писать: fix. К чему делать настолько детальное описание сделанных изменений?) Если ввести предлагаемую проверку, то отправка нового пакета в сизиф превратится в рулетку или же придётся сначала сверяться с вашим репозиторием, чтобы выбрать "правильный" релиз. Я считаю, что это совершенно неправильным подходом. autoimports не может иметь приоритет над сизифом. Vote: -1 P.S. пожалуйста, добавьте меня в blacklist рассылки таких писем.
> Если ввести предлагаемую проверку, то отправка нового пакета в сизиф > превратится в рулетку или же придётся сначала сверяться с вашим > репозиторием, чтобы выбрать "правильный" релиз. Я считаю, что это совершенно > неправильным подходом. autoimports не может иметь приоритет над сизифом. Гм. а как же больба за качество в Сизифе? Если Вы читали недавнее письмо lav@ https://lists.altlinux.org/pipermail/devel/2020-October/212112.html , там lav@ предлагает вынести нестабильную разработку в репозитории - карманы над Сизифом. И при переносе пакетов из нестабильных карманов в Сизиф естественное требование, чтобы релизы в Сизифе были БОЛЬШЕ, чем в репозиториях - карманах. autoimports это пока единственный наш нестабильный карман, только потому, что сейчас в сборочнице поддержки карманов нет. Как только появится, то должна будет появиться и поддержка проверки релизов, чтобы выкладка в Сизиф не была меньше пакетов в карманах, иначе мы быдем стрелять в ногу пользователям, ставившим пакеты из нестабильных карманов. Это общее правило, зачем делать из него исключение для autoimports? > Если ввести предлагаемую проверку, то отправка нового пакета в сизиф > превратится в рулетку или же придётся сначала сверяться с вашим репозиторием, > чтобы выбрать "правильный" релиз. Гм. при отправке "нового" perl-*.src.rpm в Сизиф рулетки нет. На 99.99% можно быть уверенным, что такой пакет уже есть в autoimports. Но вообще сборочница _уже_ проверяет релизы на сравнение с более ранними ветвями, и не принимает пакет, если такое имя уже есть. Так что элемент рулетки уже присутствует. В случае с реализацией нестабильных карманов в сборочнице, это только усугубится. Имеет смысл добавить в girar отдельную команду, которая покажет последнюю версию-релиз по всем бранчам и карманам, ассоциированную с данным имененем, что-то вроде ssh girar find-latest <name>.
(Ответ для viy на комментарий #13) > Но вообще сборочница _уже_ проверяет релизы на сравнение с более ранними > ветвями, и не принимает пакет, если такое имя уже есть с большим релизом, естественно.
(Ответ для viy на комментарий #13) > > Если ввести предлагаемую проверку, то отправка нового пакета в сизиф > > превратится в рулетку или же придётся сначала сверяться с вашим > > репозиторием, чтобы выбрать "правильный" релиз. Я считаю, что это совершенно > > неправильным подходом. autoimports не может иметь приоритет над сизифом. > > Гм. а как же больба за качество в Сизифе? Расскажите, как представленные выше релизы в федоре повышают качество в сизифе ? > Если Вы читали недавнее письмо lav@ > https://lists.altlinux.org/pipermail/devel/2020-October/212112.html , > там lav@ предлагает вынести нестабильную разработку в репозитории - карманы > над Сизифом. Вы говорите так будто с его идеей все согласились, хотя это не так и были высказаны обоснованные мысли, что предложенное делать не требуется. > И при переносе пакетов из нестабильных карманов в Сизиф > естественное требование, чтобы релизы в Сизифе были БОЛЬШЕ, чем в > репозиториях - карманах. > > autoimports это пока единственный наш нестабильный карман, только потому, > что сейчас в сборочнице поддержки карманов нет. Как только появится, то > должна будет появиться и поддержка проверки релизов, чтобы выкладка в Сизиф > не была меньше пакетов в карманах, иначе мы быдем стрелять в ногу > пользователям, ставившим пакеты из нестабильных карманов. Возможно, у вас в подвале есть машина времени и вы уже живёте в будущем, где карманы уже есть. На данный момент никих карманов в сизифе нет. Я вполне уверен, что если они будут когда-нибудь реализованы, то карманы не будут похожи на autoimports. Пока же карманы это только фантазии и я не хочу их обсуждать. > Это общее правило, зачем делать из него исключение для autoimports? Не понимаю о чём вы. > > Если ввести предлагаемую проверку, то отправка нового пакета в сизиф > > превратится в рулетку или же придётся сначала сверяться с вашим репозиторием, > чтобы выбрать "правильный" релиз. > > Гм. при отправке "нового" perl-*.src.rpm в Сизиф рулетки нет. > На 99.99% можно быть уверенным, что такой пакет уже есть в autoimports. Пока эти пакеты не в сизифе их нет. Собранный в сизиф пакет может отличаться как по составу файлов, так и по включённым опциям от того, что лежит в autoimports. То что вы предлагаете делать в письмах счастья просто некорректно по отношению к пользователям вашего же autoimports. У них произойдёт подмена одного пакета другим с другим содержимым. > Но вообще сборочница _уже_ проверяет релизы на сравнение с более ранними > ветвями, и не принимает пакет, если такое имя уже есть. Так что элемент > рулетки уже присутствует. Это не рулетка а коллизия в пределах одного репозитория, которая решается в пределах git.altlinux.org/{gears,srpms}. Все версии там, все имена там. Никакой рулетки нет. А вот когда у вас N произвольных сторонних репозиториев с дупами по именам, то сборка даже нового релиза уже существующего пакета в сизиф превращается в угадайку: в каком репозитории какая версия пакета под таким же именем (и дай бог с таким же содержимым) и не собирается ли там сейчас altI+1, которая сломает ваш релиз. > ssh girar find-latest <name>. В обсуждении карманов буду принимать участие только когда будет RFC на карманы. В самой этой идее есть ряд технических проблем. P.S. Я получил уже второе письмо от ваших роботов с практически идентичным содержимым: Autoimports: the package you uploaded to incoming is not greater Fedoraimport: the package you uploaded to incoming is not greater прекратите пожалуйста. Я не подписывался на эту рассылку и на участие в autoimports.
(Ответ для Alexey Gladkov на комментарий #15) > P.S. Я получил уже второе письмо от ваших роботов с практически идентичным > содержимым: гм. Я вмешался и руками удалил. Это, кстати, кусок работы, больший, чем если бы вам залить perl-Search-Xapian-1.2.25.2-alt6 :(
(Ответ для viy на комментарий #16) > гм. Я вмешался и руками удалил. Это, кстати, кусок работы, больший, > чем если бы вам залить perl-Search-Xapian-1.2.25.2-alt6 :( Не нужно меня упрекать. Вы сами придумали себе проблемы.
Вынужден согласиться с Алексеем и присоединиться к его требованиям не рассылать спам ментейнерам Сизифа.
К сожалению, я часто сталкивался с ситуацией "поматросил и бросил" по отношению к пакетам в autoimports. Понадобился пакет, его быстро переложили в Сизиф и забили на обновления. Потом такой пакет мешает обновлять другие пакеты perl.
а вот в обновлении в sisyphus уже могли бы подключиться роботы. только большая просьба при этом не ломать и не захламлять структуру спек-файла. если нужно положить служебную информацию, то это можно сделать в .gear/
(Ответ для viy на комментарий #19) > К сожалению, я часто сталкивался с ситуацией "поматросил и бросил" по > отношению к пакетам в autoimports. Понадобился пакет, его быстро переложили > в Сизиф и забили на обновления. Потом такой пакет мешает обновлять другие > пакеты perl. Это общая проблема любого репозитория и не специфична для autoimports. Эта проблема в равной степени относится к модулям интерпретаторов и клиентам библиотек. Вы это к чему вспомнили ? К тому, что ваш робот обновляет пакеты лучше, чем мантейнер, а мантейнеры мешают его работе ?
(Ответ для Anton Farygin на комментарий #20) > а вот в обновлении в sisyphus уже могли бы подключиться роботы. > только большая просьба при этом не ломать и не захламлять структуру > спек-файла. > если нужно положить служебную информацию, то это можно сделать в .gear/ У нас же есть некий cronbuild.
Добавляю Виталия в сс: так как обсуждаемая тема связана с нестабильными карманами, обсуждаемыми в https://lists.altlinux.org/pipermail/devel/2020-October/212112.html,
(Ответ для viy на комментарий #23) > Добавляю Виталия в сс: > так как обсуждаемая тема связана с нестабильными карманами, обсуждаемыми в > https://lists.altlinux.org/pipermail/devel/2020-October/212112.html, Лично я не буду обсуждать этот оффтопик в этой баге.
(Ответ для viy на комментарий #23) > Добавляю Виталия в сс: > так как обсуждаемая тема связана с нестабильными карманами, обсуждаемыми в > https://lists.altlinux.org/pipermail/devel/2020-October/212112.html, эта тема пример следующих вопросов, связанных х с нестабильными карманами: 1) нестабильные карманы нужно добавлять для проверки, не ниже ли релиз в Сизифе (бранче) релиза в нестабильном кармане, чтобы обеспечить корректное обновление пользователя кармана до Сизифа. 2) не урегулированная, порождает споры и конфликты, когда майнтайнер А сопровождает пакет в нестабильном кармане, а майнтайнер В выкладывает этот пакет в Сизиф (бранч). В данном случае еще и пример странного, когда майнтайнер В, выложив пакет майнтайнера А, еще и предъявляет претензии майнтайнеру А :(
(Ответ для viy на комментарий #25) > (Ответ для viy на комментарий #23) > > Добавляю Виталия в сс: > > так как обсуждаемая тема связана с нестабильными карманами, обсуждаемыми в > > https://lists.altlinux.org/pipermail/devel/2020-October/212112.html, > > эта тема пример следующих вопросов, связанных х с нестабильными карманами: > 1) нестабильные карманы нужно добавлять для проверки, не ниже ли релиз в > Сизифе (бранче) релиза в нестабильном кармане, чтобы обеспечить > корректное обновление пользователя кармана до Сизифа. Как я понимаю, пакет в autoimports должен иметь релиз вида alt0.x Тогда при сборке той же версии мантейнером сделанный вручную пакет будет иметь приоритет. Поскольку в autoimports далее не будет обновляться/собираться этот пакет, ситуация, когда в autoimports появится пакет с большей версией, не случится. (А это так работает сейчас?) > 2) не урегулированная, порождает споры и конфликты, когда майнтайнер А > сопровождает пакет в нестабильном кармане, а майнтайнер В выкладывает этот > пакет в Сизиф (бранч). На мой взгляд, выкладывание такого пакета в Сизиф (бранч) (т.е. выкладывание из кармана) должно приводить к автоматическому удалению кармана. Соответственно, такая операция должна быть требовать approve от всех, у кого в кармане есть такой пакет. > В данном случае еще и пример странного, когда майнтайнер В, выложив пакет > майнтайнера А, еще и предъявляет претензии майнтайнеру А :( репозиторий мантейнера A не принимается всерьёз... Всё это тема не для обсуждения в баге, конечно.
Очередной пакет, причём с пылу, с жару: https://packages.altlinux.org/ru/sisyphus/srpms/woof/ Причём не только с autoimports, но и с mgaimport.
Та же история с пакетом: https://packages.altlinux.org/ru/sisyphus/srpms/dexed/ И autoimports и mgaimport.
В автоимпортах, на мой взгляд, кривая версия пакета была. Вообще тащить к себе наследование версий автоматически-собранных пакетов - идея не очень. Предлагаю просто игнорировать пакеты из других дистрибутивов.
(Ответ для Michael Shigorin на комментарий #7) > Так меньше alt1_* не получится, т.к. alt0_* не сбэкпортится при надобности. Это соображение в целом устарело; возможно, в autoimports стоит класть alt0_* по умолчанию.
