* [devel] rpm в p9 @ 2019-01-18 14:59 Anton Farygin 2019-01-18 23:22 ` Dmitry V. Levin 0 siblings, 1 reply; 9+ messages in thread From: Anton Farygin @ 2019-01-18 14:59 UTC (permalink / raw) To: ALT Linux Team development discussions А я правильно понимаю, что у нас не получится сделать p9, пока в Sisyphus в rpm не будет реализована полноценная поддержка alt-gpgkeys ? Может быть, тогда есть надежда на обновление rpm-build до 4.13 ? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [devel] rpm в p9 2019-01-18 14:59 [devel] rpm в p9 Anton Farygin @ 2019-01-18 23:22 ` Dmitry V. Levin 2019-01-19 7:32 ` Anton Farygin 0 siblings, 1 reply; 9+ messages in thread From: Dmitry V. Levin @ 2019-01-18 23:22 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 811 bytes --] On Fri, Jan 18, 2019 at 05:59:03PM +0300, Anton Farygin wrote: > А я правильно понимаю, что у нас не получится сделать p9, пока в > Sisyphus в rpm не будет реализована полноценная поддержка alt-gpgkeys ? В свое время Глеб решил, что поддержка alt-gpgkeys в rpm-4.13 может подождать. Я думаю, что поддержку alt-gpgkeys в rpm можно будет добавить в любой момент, поскольку проверка подписи rpm'ом мало кому нужна, в отличие от проверки подписи в apt. > Может быть, тогда есть надежда на обновление rpm-build до 4.13 ? Никаких надежд на подобное обновление уже давно нет, тема закрыта. rpm и rpm-build -- это проекты с разными целями, задачами, и средствами. Хорошо бы почистить код rpm-build от старого барахла, конечно, и добавить нового (куда же без него), но это не горит. -- ldv [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [devel] rpm в p9 2019-01-18 23:22 ` Dmitry V. Levin @ 2019-01-19 7:32 ` Anton Farygin 2019-01-19 12:11 ` Dmitry V. Levin 0 siblings, 1 reply; 9+ messages in thread From: Anton Farygin @ 2019-01-19 7:32 UTC (permalink / raw) To: ALT Linux Team development discussions, Dmitry V. Levin 19.01.2019 2:22, Dmitry V. Levin пишет: > On Fri, Jan 18, 2019 at 05:59:03PM +0300, Anton Farygin wrote: >> А я правильно понимаю, что у нас не получится сделать p9, пока в >> Sisyphus в rpm не будет реализована полноценная поддержка alt-gpgkeys ? > В свое время Глеб решил, что поддержка alt-gpgkeys в rpm-4.13 может подождать. > > Я думаю, что поддержку alt-gpgkeys в rpm можно будет добавить в любой > момент, поскольку проверка подписи rpm'ом мало кому нужна, > в отличие от проверки подписи в apt. Если я правильно понимаю - то без добавления alt-gpgkeys в rpm у тебя его не будет на сборочнице. Т.е. - если разивать эту мысль дальше, то я предлагаю сейчас не тащить изменения rpm в p8, а довести rpm в Sisyphus до состояния, когда его можно будет полноценно использовать для работы. А в *8 ветках оставить как есть сейчас. > >> Может быть, тогда есть надежда на обновление rpm-build до 4.13 > Никаких надежд на подобное обновление уже давно нет, тема закрыта. > rpm и rpm-build -- это проекты с разными целями, задачами, и средствами. > > Хорошо бы почистить код rpm-build от старого барахла, конечно, > и добавить нового (куда же без него), но это не горит. У всех по разному "не горит" - А вот такие вещи как планируется решить ? https://bugzilla.altlinux.org/show_bug.cgi?id=35492 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [devel] rpm в p9 2019-01-19 7:32 ` Anton Farygin @ 2019-01-19 12:11 ` Dmitry V. Levin 2019-01-19 13:37 ` Anton Farygin 2019-01-19 17:21 ` Leonid Krivoshein 0 siblings, 2 replies; 9+ messages in thread From: Dmitry V. Levin @ 2019-01-19 12:11 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 1769 bytes --] On Sat, Jan 19, 2019 at 10:32:07AM +0300, Anton Farygin wrote: > 19.01.2019 2:22, Dmitry V. Levin пишет: > > On Fri, Jan 18, 2019 at 05:59:03PM +0300, Anton Farygin wrote: > >> А я правильно понимаю, что у нас не получится сделать p9, пока в > >> Sisyphus в rpm не будет реализована полноценная поддержка alt-gpgkeys ? > > В свое время Глеб решил, что поддержка alt-gpgkeys в rpm-4.13 может подождать. > > > > Я думаю, что поддержку alt-gpgkeys в rpm можно будет добавить в любой > > момент, поскольку проверка подписи rpm'ом мало кому нужна, > > в отличие от проверки подписи в apt. > > Если я правильно понимаю - то без добавления alt-gpgkeys в rpm у тебя > его не будет на сборочнице. Т.е. - если разивать эту мысль дальше, то я > предлагаю сейчас не тащить изменения rpm в p8, Поддержка disttag при установке/обновлении пакетов там нужна уже вчера. > а довести rpm в Sisyphus > до состояния, когда его можно будет полноценно использовать для работы. > > А в *8 ветках оставить как есть сейчас. Как сейчас тоже нехорошо, потому что apt неисправимо плохо работает с промежуточными межпакетными зависимостями вида ".${RPM_STRICT_INTERDEPS}-NEVR". > >> Может быть, тогда есть надежда на обновление rpm-build до 4.13 > > Никаких надежд на подобное обновление уже давно нет, тема закрыта. > > rpm и rpm-build -- это проекты с разными целями, задачами, и средствами. > > > > Хорошо бы почистить код rpm-build от старого барахла, конечно, > > и добавить нового (куда же без него), но это не горит. > > У всех по разному "не горит" - > > А вот такие вещи как планируется решить ? > https://bugzilla.altlinux.org/show_bug.cgi?id=35492 Это rpm. Пока redhat не захочет это исправить, в rpm.org это не исправят. -- ldv [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [devel] rpm в p9 2019-01-19 12:11 ` Dmitry V. Levin @ 2019-01-19 13:37 ` Anton Farygin 2019-01-19 14:02 ` Dmitry V. Levin 2019-01-19 17:21 ` Leonid Krivoshein 1 sibling, 1 reply; 9+ messages in thread From: Anton Farygin @ 2019-01-19 13:37 UTC (permalink / raw) To: ALT Linux Team development discussions, Dmitry V. Levin 19.01.2019 15:11, Dmitry V. Levin пишет: > On Sat, Jan 19, 2019 at 10:32:07AM +0300, Anton Farygin wrote: >> 19.01.2019 2:22, Dmitry V. Levin пишет: >>> On Fri, Jan 18, 2019 at 05:59:03PM +0300, Anton Farygin wrote: >>>> А я правильно понимаю, что у нас не получится сделать p9, пока в >>>> Sisyphus в rpm не будет реализована полноценная поддержка alt-gpgkeys ? >>> В свое время Глеб решил, что поддержка alt-gpgkeys в rpm-4.13 может подождать. >>> >>> Я думаю, что поддержку alt-gpgkeys в rpm можно будет добавить в любой >>> момент, поскольку проверка подписи rpm'ом мало кому нужна, >>> в отличие от проверки подписи в apt. >> Если я правильно понимаю - то без добавления alt-gpgkeys в rpm у тебя >> его не будет на сборочнице. Т.е. - если разивать эту мысль дальше, то я >> предлагаю сейчас не тащить изменения rpm в p8, > Поддержка disttag при установке/обновлении пакетов там нужна уже вчера. Согласен. Точнее позавчера. Но в позавчера мы её добавить не сможем. Поэтому нужно добавить в сейчас и использовать это завтра (в p9). > >> а довести rpm в Sisyphus >> до состояния, когда его можно будет полноценно использовать для работы. >> >> А в *8 ветках оставить как есть сейчас. > Как сейчас тоже нехорошо, потому что apt неисправимо плохо работает > с промежуточными межпакетными зависимостями вида > ".${RPM_STRICT_INTERDEPS}-NEVR". Второй вариант - это вернуть на место %ubt для stable веток, а в сизифе сделать его во что-то нейтральное, например просто цифрой. При этом считать эксперимент в p8 неудавшимся. Пересобирать пока не так много. > >>>> Может быть, тогда есть надежда на обновление rpm-build до 4.13 >>> Никаких надежд на подобное обновление уже давно нет, тема закрыта. >>> rpm и rpm-build -- это проекты с разными целями, задачами, и средствами. >>> >>> Хорошо бы почистить код rpm-build от старого барахла, конечно, >>> и добавить нового (куда же без него), но это не горит. >> У всех по разному "не горит" - >> >> А вот такие вещи как планируется решить ? >> https://bugzilla.altlinux.org/show_bug.cgi?id=35492 > Это rpm. Пока redhat не захочет это исправить, в rpm.org это не исправят. А зачем это исправлять RH, если они могут написал prein скрипт, который может это закостылять ? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [devel] rpm в p9 2019-01-19 13:37 ` Anton Farygin @ 2019-01-19 14:02 ` Dmitry V. Levin 2019-01-19 16:28 ` Anton Farygin 0 siblings, 1 reply; 9+ messages in thread From: Dmitry V. Levin @ 2019-01-19 14:02 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 2628 bytes --] On Sat, Jan 19, 2019 at 04:37:15PM +0300, Anton Farygin wrote: > 19.01.2019 15:11, Dmitry V. Levin пишет: > > On Sat, Jan 19, 2019 at 10:32:07AM +0300, Anton Farygin wrote: > >> 19.01.2019 2:22, Dmitry V. Levin пишет: > >>> On Fri, Jan 18, 2019 at 05:59:03PM +0300, Anton Farygin wrote: > >>>> А я правильно понимаю, что у нас не получится сделать p9, пока в > >>>> Sisyphus в rpm не будет реализована полноценная поддержка alt-gpgkeys ? > >>> В свое время Глеб решил, что поддержка alt-gpgkeys в rpm-4.13 может подождать. > >>> > >>> Я думаю, что поддержку alt-gpgkeys в rpm можно будет добавить в любой > >>> момент, поскольку проверка подписи rpm'ом мало кому нужна, > >>> в отличие от проверки подписи в apt. > >> Если я правильно понимаю - то без добавления alt-gpgkeys в rpm у тебя > >> его не будет на сборочнице. Т.е. - если разивать эту мысль дальше, то я > >> предлагаю сейчас не тащить изменения rpm в p8, > > Поддержка disttag при установке/обновлении пакетов там нужна уже вчера. > Согласен. Точнее позавчера. Но в позавчера мы её добавить не сможем. > Поэтому нужно добавить в сейчас и использовать это завтра (в p9). > > > >> а довести rpm в Sisyphus > >> до состояния, когда его можно будет полноценно использовать для работы. > >> > >> А в *8 ветках оставить как есть сейчас. > > Как сейчас тоже нехорошо, потому что apt неисправимо плохо работает > > с промежуточными межпакетными зависимостями вида > > ".${RPM_STRICT_INTERDEPS}-NEVR". > > Второй вариант - это вернуть на место %ubt для stable веток, а в сизифе > сделать его во что-то нейтральное, например просто цифрой. Давайте оставим уже %ubt в покое. > При этом считать эксперимент в p8 неудавшимся. Пересобирать пока не так > много. > > > >>>> Может быть, тогда есть надежда на обновление rpm-build до 4.13 > >>> Никаких надежд на подобное обновление уже давно нет, тема закрыта. > >>> rpm и rpm-build -- это проекты с разными целями, задачами, и средствами. > >>> > >>> Хорошо бы почистить код rpm-build от старого барахла, конечно, > >>> и добавить нового (куда же без него), но это не горит. > >> У всех по разному "не горит" - > >> > >> А вот такие вещи как планируется решить ? > >> https://bugzilla.altlinux.org/show_bug.cgi?id=35492 > > Это rpm. Пока redhat не захочет это исправить, в rpm.org это не исправят. > > А зачем это исправлять RH, если они могут написал prein скрипт, который > может это закостылять ? Вот за этот подход я так люблю redhat и другие коммерческие компании, которые в угоду сиюминутным интересам предлагают нам десятилетиями жить с костылями. -- ldv [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [devel] rpm в p9 2019-01-19 14:02 ` Dmitry V. Levin @ 2019-01-19 16:28 ` Anton Farygin 0 siblings, 0 replies; 9+ messages in thread From: Anton Farygin @ 2019-01-19 16:28 UTC (permalink / raw) To: devel 19.01.2019 17:02, Dmitry V. Levin пишет: > On Sat, Jan 19, 2019 at 04:37:15PM +0300, Anton Farygin wrote: >> 19.01.2019 15:11, Dmitry V. Levin пишет: >>> On Sat, Jan 19, 2019 at 10:32:07AM +0300, Anton Farygin wrote: >>>> 19.01.2019 2:22, Dmitry V. Levin пишет: >>>>> On Fri, Jan 18, 2019 at 05:59:03PM +0300, Anton Farygin wrote: >>>>>> А я правильно понимаю, что у нас не получится сделать p9, пока в >>>>>> Sisyphus в rpm не будет реализована полноценная поддержка alt-gpgkeys ? >>>>> В свое время Глеб решил, что поддержка alt-gpgkeys в rpm-4.13 может подождать. >>>>> >>>>> Я думаю, что поддержку alt-gpgkeys в rpm можно будет добавить в любой >>>>> момент, поскольку проверка подписи rpm'ом мало кому нужна, >>>>> в отличие от проверки подписи в apt. >>>> Если я правильно понимаю - то без добавления alt-gpgkeys в rpm у тебя >>>> его не будет на сборочнице. Т.е. - если разивать эту мысль дальше, то я >>>> предлагаю сейчас не тащить изменения rpm в p8, >>> Поддержка disttag при установке/обновлении пакетов там нужна уже вчера. >> Согласен. Точнее позавчера. Но в позавчера мы её добавить не сможем. >> Поэтому нужно добавить в сейчас и использовать это завтра (в p9). >>>> а довести rpm в Sisyphus >>>> до состояния, когда его можно будет полноценно использовать для работы. >>>> >>>> А в *8 ветках оставить как есть сейчас. >>> Как сейчас тоже нехорошо, потому что apt неисправимо плохо работает >>> с промежуточными межпакетными зависимостями вида >>> ".${RPM_STRICT_INTERDEPS}-NEVR". >> Второй вариант - это вернуть на место %ubt для stable веток, а в сизифе >> сделать его во что-то нейтральное, например просто цифрой. > Давайте оставим уже %ubt в покое. Ну вы же пытаетесь реализовать его аналог. Точнее уже реализовали, но гораздо более сложным способом и более кривой. К ubt была одна претензия - пакет меняется после пересборки. Но и disttag меняется после пересборки. В чём профит ? Пока что только одни проблемы, при этом с некоторыми из них мы ещё не сталкивались. > >> При этом считать эксперимент в p8 неудавшимся. Пересобирать пока не так >> много. >>>>>> Может быть, тогда есть надежда на обновление rpm-build до 4.13 >>>>> Никаких надежд на подобное обновление уже давно нет, тема закрыта. >>>>> rpm и rpm-build -- это проекты с разными целями, задачами, и средствами. >>>>> >>>>> Хорошо бы почистить код rpm-build от старого барахла, конечно, >>>>> и добавить нового (куда же без него), но это не горит. >>>> У всех по разному "не горит" - >>>> >>>> А вот такие вещи как планируется решить ? >>>> https://bugzilla.altlinux.org/show_bug.cgi?id=35492 >>> Это rpm. Пока redhat не захочет это исправить, в rpm.org это не исправят. >> А зачем это исправлять RH, если они могут написал prein скрипт, который >> может это закостылять ? > Вот за этот подход я так люблю redhat и другие коммерческие компании, > которые в угоду сиюминутным интересам предлагают нам десятилетиями жить > с костылями. > > А вот за этот подход мне так не нравится наша система - мы будем десятилетиями страдать, но без костылей. При этом выше ты пишешь что пока RedHat это не исправит - в rpm не появится. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [devel] rpm в p9 2019-01-19 12:11 ` Dmitry V. Levin 2019-01-19 13:37 ` Anton Farygin @ 2019-01-19 17:21 ` Leonid Krivoshein 2019-01-19 17:50 ` Anton Farygin 1 sibling, 1 reply; 9+ messages in thread From: Leonid Krivoshein @ 2019-01-19 17:21 UTC (permalink / raw) To: devel 19.01.2019 15:11, Dmitry V. Levin пишет: > On Sat, Jan 19, 2019 at 10:32:07AM +0300, Anton Farygin wrote: > [...] >> а довести rpm в Sisyphus >> до состояния, когда его можно будет полноценно использовать для работы. >> >> А в *8 ветках оставить как есть сейчас. > Как сейчас тоже нехорошо, потому что apt неисправимо плохо работает Посмотрев исходники APT'а (нашего и современного Дебиновского), могу сказать, что здесь стоит поставить точку. Неисправимая ошибка в дизайне. На dist-upgrade он непредсказуем из-за алгоритма весов и приоритетов. У нас в RPM, ко всему прочему, поля приоритета просто нет. Алгоритм разрешения конфликтов отлично справляется в пределах одной частной машины, но если взять хотя бы две одинаковые машины с полностью одинаковым набором пакетов и начать обновлять их в разное время, то рано или поздно не только пакетные базы разойдутся, но и на одной из них могут быть вынесены ключевые для исходного решения пакеты. Если сильно упростить: первоначальная установка системы -- это apt-get install A B C (со всеми зависимостями, которые мы конечно не указываем), тогда как apt-get dist-upgrade -- это отнюдь не повторение этой операции, а игра в лотерею "мне повезёт". Но это чисто поворчать, просто так это не исправить. Использование /etc/apt/pkgpriorities с умом лишь уменьшает вероятность серьёзных разъездов и заставляет APT хотя бы предупредить при выносе критически важных пакетов. Но это укрепляет лишь 0-й уровень графа зависимостей исходного решения, гарантий это всё равно не даёт. Другими словами, при нашей воспроизводимой сборке пакетов имеем непредсказуемую процедуру обновления установленных решений, в том числе, зависимую от времени обновления. > с промежуточными межпакетными зависимостями вида > ".${RPM_STRICT_INTERDEPS}-NEVR". > [...] -- Best regards, Leonid Krivoshein. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [devel] rpm в p9 2019-01-19 17:21 ` Leonid Krivoshein @ 2019-01-19 17:50 ` Anton Farygin 0 siblings, 0 replies; 9+ messages in thread From: Anton Farygin @ 2019-01-19 17:50 UTC (permalink / raw) To: ALT Linux Team development discussions, Leonid Krivoshein 19.01.2019 20:21, Leonid Krivoshein пишет: > > 19.01.2019 15:11, Dmitry V. Levin пишет: >> On Sat, Jan 19, 2019 at 10:32:07AM +0300, Anton Farygin wrote: >> [...] >>> а довести rpm в Sisyphus >>> до состояния, когда его можно будет полноценно использовать для работы. >>> >>> А в *8 ветках оставить как есть сейчас. >> Как сейчас тоже нехорошо, потому что apt неисправимо плохо работает > > Посмотрев исходники APT'а (нашего и современного Дебиновского), могу > сказать, что здесь стоит поставить точку. Неисправимая ошибка в > дизайне. На dist-upgrade он непредсказуем из-за алгоритма весов и > приоритетов. У нас в RPM, ко всему прочему, поля приоритета просто > нет. Алгоритм разрешения конфликтов отлично справляется в пределах > одной частной машины, но если взять хотя бы две одинаковые машины с > полностью одинаковым набором пакетов и начать обновлять их в разное > время, то рано или поздно не только пакетные базы разойдутся, но и на > одной из них могут быть вынесены ключевые для исходного решения пакеты. > > Если сильно упростить: первоначальная установка системы -- это apt-get > install A B C (со всеми зависимостями, которые мы конечно не > указываем), тогда как apt-get dist-upgrade -- это отнюдь не повторение > этой операции, а игра в лотерею "мне повезёт". Но это чисто поворчать, > просто так это не исправить. Использование /etc/apt/pkgpriorities с > умом лишь уменьшает вероятность серьёзных разъездов и заставляет APT > хотя бы предупредить при выносе критически важных пакетов. Но это > укрепляет лишь 0-й уровень графа зависимостей исходного решения, > гарантий это всё равно не даёт. > > Другими словами, при нашей воспроизводимой сборке пакетов имеем > непредсказуемую процедуру обновления установленных решений, в том > числе, зависимую от времени обновления. К воспроизводимости сборки тоже есть вопросы - в последнее время очень часто Beehive ругается тогда, когда локально проблема сборки не воспроизводится. К счастью, чаще всего это race в результате параллельной сборки. А солвер в apt давно уже надо кому-то переписать, но для этого нужно поменять нашу пакетную базу - избавиться от виртуальных пакетов, например, что бы не было одинаковых provides у разных пакетов. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-01-19 17:50 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-01-18 14:59 [devel] rpm в p9 Anton Farygin 2019-01-18 23:22 ` Dmitry V. Levin 2019-01-19 7:32 ` Anton Farygin 2019-01-19 12:11 ` Dmitry V. Levin 2019-01-19 13:37 ` Anton Farygin 2019-01-19 14:02 ` Dmitry V. Levin 2019-01-19 16:28 ` Anton Farygin 2019-01-19 17:21 ` Leonid Krivoshein 2019-01-19 17:50 ` Anton Farygin
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git