41023 2021-09-28 14:55:28 +0300 Поле Packager должно совпадать с тем, кто делал тэг на сборку (или src.rpm) 2025-02-10 18:13:06 +0300 1 1 2 Infrastructure Infrastructure girar unspecified x86_64 Linux NEW P5 major --- 41544 41942 43772 49104 40765 41684 1 rider placeholder aen glebfm iv ldv rider vseleznv cas oldest_to_newest 203313 0 rider 2021-09-28 14:55:28 +0300 Виталий Липатов собирал пакет, в котором в поле Packager написан qa@packages.altlinux.org Соответственно возникает вывод, что кто угодно можно собрать какой-то произвольный пакет и написать в поле Packager не имеющего никакого к этому отношения человека, вплоть до вообще не существующего ментейнера ? Выглядит, по крайней мере, не очень красиво. $ rpm -qp --qf '%{PACKAGER}\n' http://git.altlinux.org/tasks/archive/done/_276/283196/build/100/x86_64/srpm/gdal-3.0.4-alt1.5.src.rpm ALT QA Team <qa@packages.altlinux.org> Предлагаю зафиксировать в проверке что в поле Packager если что-то и будет прописано, то оно должно полностью соответствовать тому, кто отправляет задание на сборку. Ну или, в идеале, запретить поле Packager - оно сейчас неплохо формируется само на основании gpg подписи отправившего пакет человека. 203314 1 ldv 2021-09-28 14:58:50 +0300 Я раньше добавлял поле Packager в пакеты, которым делал NMU, потому что не хотел попадать в packager'ы, которых считают мантейнерами. 203317 2 rider 2021-09-28 15:07:19 +0300 Очень сложно понятие - кого считать сопровождающим пакета. Вот ещё один пример, в котором настоящий ментейнер не соответствует содержимому поля Packager: rpm -qp --qf '%{PACKAGER}\n' --changelog http://git.altlinux.org/tasks/archive/done/_279/286036/build/100/x86_64/srpm/python3-module-google-auth-library-python-2.2.0-alt1.src.rpm Т.е. понятно что поле Packager в этом случае надо считать не как 'ответственный за пакет' а как 'человек, последний раз собравший данный пакет'. В этом случае попадание в это поле не означает ничего страшного. А сопровождающего пакет можно вычислить по changelog, используя для этого не очень сложную формулу. 203394 3 rider 2021-09-30 16:37:29 +0300 Так какой вердикт ? С этим полем есть, на мой взгляд, весьма серьёзная проблема - например у нас Стас Иевлев сопровождает 49 пакетов в Sisyphus. Регулярно. Сам этого не подозревая. Помимо моральной стороны дела тут может вылезти и юридическая. На мой взгляд требуется вносить изменения безотлагательно. 203396 4 vseleznv 2021-09-30 17:50:45 +0300 (In reply to Anton Farygin from comment #2) > Т.е. понятно что поле Packager в этом случае надо считать не как > 'ответственный за пакет' а как 'человек, последний раз собравший данный > пакет'. Согласен. > В этом случае попадание в это поле не означает ничего страшного. 203405 5 ldv 2021-09-30 19:50:19 +0300 Надеюсь, я смогу подумать на эту тему на следующей неделе. 203732 6 rider 2021-10-12 21:01:04 +0300 Я примерно посмотрел по количеству пакетов, в которых прописан Packager - это 6669. А вот с числом пакетов, в которых Packager не совпадает с %changelog начинается совсем интересное - много кто пишет в %changelog совсем не ту же запись, которая есть в %packager. У кого-то просто отличается домен (altlinux.ru vs altlinux.org), а кто-то в Packager называет себя одним образом, а в %changelog другим. Плюс ещё есть группы - что-то вроде kernel team, у пакетов которых в Packager прописано Kernel Maintainers Team <kernel@packages.altlinux.org> и который на самом деле вообще не имеет никакого смысла, т.к. врятли кем-то читаем и вместо этого имени можно было бы написать placeholder. В итоге я разными манипуляциями получил примерно около пары тысяч пакетов, в которых packager и last change всё-таки не совпадает. Но можно пойти чуть дальше и просто на уровне girar писать в Packager last changelog entry, валидируя последнюю на соотвествие каким-то базовы правилам. Многие из тех разработчиков, с которыми я пообщался вообще не обращают внимания на эту запись, а кто-то её использует вредным образом, отказываясь принимать на себя поддержку фактически поддерживаемому пакету (например, 389-ds) Но в целом все за то, что бы были понятные правила использования данного тэга rpm. 203881 7 rider 2021-10-18 08:30:12 +0300 Но есть некоторые пакеты, в которых совершенно не хочется становиться Packager'ом. Например, handbrake Выручает NMU: - если встречается NMU, то можно игнорировать эту changelog entry и переходить к следующией и так до тех пор, пока не будет выяснен истинный Packager. 205378 8 rider 2021-11-27 12:29:01 +0300 Дима, удалось подумать над этой проблемой ? Мы добавили отображение пакетов мейнтейнера по ACL, но это всё равно не покрывает всех возможных случаев, когда настоящий мейнтейнер не соответствует ни записи в ACL, ни тэгу Packager. https://beta.packages.altlinux.org/ru/sisyphus/maintainers/ldv/srpms?by_acl=nick Точнее говоря ACL вообще может не соответствовать действительности и это может быть правильным (так задумано). Я, честно говоря, и сам переодически забываю удалять поле Packager, подхватывая пакеты с @nobody. Самый явный пример таких подхваченных пакетов можно наблюдать тут: https://beta.packages.altlinux.org/ru/sisyphus/maintainers/real/srpms?order_by=-buildtime 240298 9 iv 2024-01-18 09:56:32 +0300 (In reply to Anton Farygin from comment #0) > Виталий Липатов собирал пакет, в котором в поле Packager написан > qa@packages.altlinux.org (In reply to Anton Farygin from comment #6) > Плюс ещё есть группы - что-то вроде kernel team, у пакетов которых в > Packager прописано Kernel Maintainers Team <kernel@packages.altlinux.org> > и который на самом деле вообще не имеет никакого смысла, т.к. врятли кем-то > читаем и вместо этого имени можно было бы написать placeholder. При попытке найти документацию на тег Packager, я нашёл такое: https://www.altlinux.org/Packager_Teams Мне кажется нормальным, что пакет поддерживается группой. Мне кажется печальным, что у нас практически не сложилось такой практики. Конечно важно, - чтобы группа существовала - чтобы указанный e-mail работал (kernel@packages.altlinux.org вроде работает) - что qa@, everybody@ и nobody@ не поддерживают пакеты, так что packager'ами быть не могут. 258995 10 rider 2025-02-10 18:13:06 +0300 С группами тоже проблем. Сейчас лидер группы зачастую управляет её составом, что приводит к захламлению групп - группы перестают отвечать за реальное положение дел.