Bug 27419

Summary: add src.list from autoimports.altlinux.org to the lists checked
Product: Infrastructure Reporter: viy <viy>
Component: girarAssignee: placeholder <placeholder>
Status: NEW --- QA Contact: Nobody's working on this, feel free to take it <nobody>
Severity: enhancement    
Priority: P3 CC: arbars, asy, bystrov.arterm, enp, evg, glebfm, grenka, ildar, lav, ldv, legion, mike, neff, real.altlinux.org, rider, zerg
Version: unspecified   
Hardware: all   
OS: Linux   
URL: ftp://autoimports.altlinux.org/pub/ALTLinux/autoimports/Sisyphus/files/list/src.list

Description viy 2012-06-07 20:40:30 MSK
в girar проверяется, (в gb-task-repo-vercheck?) чтобы поступивший пакет
был не моложе уже имеющихся в бранчах пакетов.

Так как autoimports.altlinux.org скоро станет публичным расширением Сизифа,
прошу добавить в эту проверку и пакеты из autoimports.
src.list для пакетов из autoimports доступен по адресу:
http://autoimports.altlinux.org/pub/ALTLinux/autoimports/Sisyphus/files/list/src.list
Comment 1 viy 2012-06-08 14:07:54 MSK
Проблема актуальна:
люди уже начинают интересоваться пакетами из autoimports,
а раз эти пакеты уже могут стоять у пользователей, то нужно проверять,
что пакеты, заливаемые в Сизиф, вытесняют пакеты из autoimports.
Comment 2 Dmitry V. Levin 2012-06-08 14:14:54 MSK
Прежде чем пакеты из autoimports начнут влиять на правила приема пакетов в Сизиф и бранчи, надо зафиксировать правила, по которым пакеты попадают в autoimports.

Иначе получается, что на пакеты в Сизиф и бранчи накладываются достаточно произвольные ограничения, вплоть до невозможности отправить пакет в бранч, поскольку, с одной стороны, он не должен быть свежее сизифного, и, с другой стороны, он должен быть свежее импортированного.
Comment 3 viy 2012-06-08 14:31:01 MSK
(В ответ на комментарий №2)
> надо зафиксировать правила, по которым пакеты попадают в autoimports.

Сейчас бранчей в autoimports нет; таким образом, на пакеты в бранчах они
не влияют. В момент форка p7 из Сизифа я хочу сделать аналогичный
форк и в autoimports, получив, таким образом, autoimports/p7.

Тогда и для пакетов в p7/branch необходимо будет проверять, что они 
старше, чем пакеты в autoimports/p7.
Ограничений же, чтобы пакет в branch был моложе пакета в autoimports/Sisyphus,
лучше не накладывать.
С другой стороны, это не слишком сильное ограничение: раз пакет в autoimports,
то его нет в настоящем сизифе и его можно смело туда залить.
Comment 4 viy 2012-06-08 14:38:05 MSK
Т.е. избыточных ограничений лучше не накладывать -
для этого для проверки по версиям снизу использовать смерженный список пакетов,
Sisyphus/classic+Sisyphus/autoimports,
а для проверки в бранчах по версиям сверху использовать чистый список пакетов
Sisyphus/classic.

Также, удаление пакетов из Sisyphus/autoimports будет проводиться по крону раз в сутки, поэтому нормально, что src.list для пакетов из autoimports может содержать names пакетов, которые уже залиты в сизиф.
Поэтому мерж src.list из autoimports и из Sisyphus/classic надо делать аккуратно.
Comment 5 viy 2012-10-12 10:34:14 MSK
Проблема по прежнему актуальна,
в Сизиф заливаются пакеты с релизом меньше чем в autoimports
(последний пример perl-Devel-Autoflush) 
что может создавать проблемы с обновлением из Сизифа.
Comment 6 Sergey V Turchin 2013-11-14 15:23:30 MSK
(В ответ на комментарий №5)
> в Сизиф заливаются пакеты с релизом меньше чем в autoimports
Я бы сказал наоборот, в autoimports заливаются пакеты с заведомо большим релизом, чем нужно.
Comment 7 Michael Shigorin 2013-12-07 05:05:41 MSK
Так меньше alt1_* не получится, т.к. alt0_* не сбэкпортится при надобности.
Comment 8 Sergey V Turchin 2013-12-09 16:45:52 MSK
(В ответ на комментарий №7)
> Так меньше alt1_* не получится, т.к. alt0_* не сбэкпортится при надобности.
Нужно получать такие, чтоб сбэкпортился.
Comment 9 Sergey Y. Afonin 2016-04-06 13:32:28 MSK
Может, пока суть да дело, хотябы предупреждение в лог сборки выдавать ? А то, бывает, пост фактум узнаёшь, что пакет-то уже был в autoimports.
Comment 10 Grigory Ustinov 2018-06-09 13:52:38 MSK
Проблема по-прежнему актуальна: python-module-apipkg
Comment 11 Arbars 2019-11-26 15:34:47 MSK
Подтверждаю актуальность, пакет eureka:
https://packages.altlinux.org/ru/sisyphus/srpms/eureka
Comment 12 Alexey Gladkov 2020-10-16 03:21:46 MSK
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 рассылки таких писем.
Comment 13 viy 2020-10-16 13:10:36 MSK
> Если ввести предлагаемую проверку, то отправка нового пакета в сизиф
> превратится в рулетку или же придётся сначала сверяться с вашим
> репозиторием, чтобы выбрать "правильный" релиз. Я считаю, что это совершенно
> неправильным подходом. 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>.
Comment 14 viy 2020-10-16 13:11:26 MSK
(Ответ для viy на комментарий #13)
> Но вообще сборочница _уже_ проверяет релизы на сравнение с более ранними
> ветвями, и не принимает пакет, если такое имя уже есть 
с большим релизом, естественно.
Comment 15 Alexey Gladkov 2020-10-16 14:01:35 MSK
(Ответ для 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.
Comment 16 viy 2020-10-16 14:21:59 MSK
(Ответ для Alexey Gladkov на комментарий #15)
> P.S. Я получил уже второе письмо от ваших роботов с практически идентичным
> содержимым:

гм. Я вмешался и руками удалил. Это, кстати, кусок работы, больший,
чем если бы вам залить perl-Search-Xapian-1.2.25.2-alt6 :(
Comment 17 Alexey Gladkov 2020-10-16 14:32:06 MSK
(Ответ для viy на комментарий #16)
> гм. Я вмешался и руками удалил. Это, кстати, кусок работы, больший,
> чем если бы вам залить perl-Search-Xapian-1.2.25.2-alt6 :(

Не нужно меня упрекать. Вы сами придумали себе проблемы.
Comment 18 Олег Соловьев 2020-10-16 14:32:33 MSK
Вынужден согласиться с Алексеем и присоединиться к его требованиям не рассылать спам ментейнерам Сизифа.
Comment 19 viy 2020-10-16 14:56:10 MSK
К сожалению, я часто сталкивался с ситуацией "поматросил и бросил" по отношению к пакетам в autoimports. Понадобился пакет, его быстро переложили в Сизиф и забили на обновления. Потом такой пакет мешает обновлять другие пакеты perl.
Comment 20 Anton Farygin 2020-10-16 15:12:15 MSK
а вот в обновлении в sisyphus уже могли бы подключиться роботы.
только большая просьба при этом не ломать и не захламлять структуру спек-файла.
если нужно положить служебную информацию, то это можно сделать в .gear/
Comment 21 Alexey Gladkov 2020-10-16 15:14:43 MSK
(Ответ для viy на комментарий #19)
> К сожалению, я часто сталкивался с ситуацией "поматросил и бросил" по
> отношению к пакетам в autoimports. Понадобился пакет, его быстро переложили
> в Сизиф и забили на обновления. Потом такой пакет мешает обновлять другие
> пакеты perl.

Это общая проблема любого репозитория и не специфична для autoimports. Эта проблема в равной степени относится к модулям интерпретаторов и клиентам библиотек.

Вы это к чему вспомнили ?
К тому, что ваш робот обновляет пакеты лучше, чем мантейнер, а мантейнеры мешают его работе ?
Comment 22 Alexey Gladkov 2020-10-16 15:17:58 MSK
(Ответ для Anton Farygin на комментарий #20)
> а вот в обновлении в sisyphus уже могли бы подключиться роботы.
> только большая просьба при этом не ломать и не захламлять структуру
> спек-файла.
> если нужно положить служебную информацию, то это можно сделать в .gear/

У нас же есть некий cronbuild.
Comment 23 viy 2020-10-16 15:25:21 MSK
Добавляю Виталия в сс:
так как обсуждаемая тема связана с нестабильными карманами, обсуждаемыми в https://lists.altlinux.org/pipermail/devel/2020-October/212112.html,
Comment 24 Alexey Gladkov 2020-10-16 15:32:01 MSK
(Ответ для viy на комментарий #23)
> Добавляю Виталия в сс:
> так как обсуждаемая тема связана с нестабильными карманами, обсуждаемыми в
> https://lists.altlinux.org/pipermail/devel/2020-October/212112.html,

Лично я не буду обсуждать этот оффтопик в этой баге.
Comment 25 viy 2020-10-16 15:40:24 MSK
(Ответ для viy на комментарий #23)
> Добавляю Виталия в сс:
> так как обсуждаемая тема связана с нестабильными карманами, обсуждаемыми в
> https://lists.altlinux.org/pipermail/devel/2020-October/212112.html,

эта тема пример следующих вопросов, связанных х с нестабильными карманами:
1) нестабильные карманы нужно добавлять для проверки, не ниже ли релиз в Сизифе (бранче) релиза в нестабильном кармане, чтобы обеспечить
корректное обновление пользователя кармана до Сизифа.

2) не урегулированная, порождает споры и конфликты, когда майнтайнер А сопровождает пакет в нестабильном кармане, а майнтайнер В выкладывает этот пакет в Сизиф (бранч).

В данном случае еще и пример странного, когда майнтайнер В, выложив пакет майнтайнера А, еще и предъявляет претензии майнтайнеру А :(
Comment 26 Vitaly Lipatov 2020-10-16 18:05:12 MSK
(Ответ для viy на комментарий #25)
> (Ответ для viy на комментарий #23)
> > Добавляю Виталия в сс:
> > так как обсуждаемая тема связана с нестабильными карманами, обсуждаемыми в
> > https://lists.altlinux.org/pipermail/devel/2020-October/212112.html,
> 
> эта тема пример следующих вопросов, связанных х с нестабильными карманами:
> 1) нестабильные карманы нужно добавлять для проверки, не ниже ли релиз в
> Сизифе (бранче) релиза в нестабильном кармане, чтобы обеспечить
> корректное обновление пользователя кармана до Сизифа.
Как я понимаю, пакет в autoimports должен иметь релиз вида alt0.x
Тогда при сборке той же версии мантейнером сделанный вручную пакет будет иметь приоритет.

Поскольку в autoimports далее не будет обновляться/собираться этот пакет, ситуация, когда в autoimports появится пакет с большей версией, не случится. (А это так работает сейчас?)

> 2) не урегулированная, порождает споры и конфликты, когда майнтайнер А
> сопровождает пакет в нестабильном кармане, а майнтайнер В выкладывает этот
> пакет в Сизиф (бранч).
На мой взгляд, выкладывание такого пакета в Сизиф (бранч) (т.е. выкладывание из кармана) должно приводить к автоматическому удалению кармана. Соответственно, такая операция должна быть требовать approve от всех, у кого в кармане есть такой пакет.

> В данном случае еще и пример странного, когда майнтайнер В, выложив пакет
> майнтайнера А, еще и предъявляет претензии майнтайнеру А :(
репозиторий мантейнера A не принимается всерьёз...

Всё это тема не для обсуждения в баге, конечно.
Comment 27 arbars@altlinux.org 2022-09-21 22:58:50 MSK
Очередной пакет, причём с пылу, с жару:
https://packages.altlinux.org/ru/sisyphus/srpms/woof/
Причём не только с autoimports, но и с mgaimport.
Comment 28 Aleksandr Yukhnenko 2024-02-01 13:56:47 MSK
Та же история с пакетом:
https://packages.altlinux.org/ru/sisyphus/srpms/dexed/
И autoimports и mgaimport.
Comment 29 Anton Farygin 2024-02-01 15:26:09 MSK
В автоимпортах, на мой взгляд, кривая версия пакета была. 
Вообще тащить к себе наследование версий автоматически-собранных пакетов - идея не очень.
Предлагаю просто игнорировать пакеты из других дистрибутивов.