Bug 27419

Проблема актуальна:
люди уже начинают интересоваться пакетами из 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_* по умолчанию.