[devel] rpm в p9

[devel] rpm в p9

[Anton Farygin]

А я правильно понимаю, что у нас не получится сделать p9, пока в 
Sisyphus в rpm не будет реализована полноценная поддержка alt-gpgkeys ?
Может быть, тогда есть надежда на обновление rpm-build до 4.13 ?

Re: [devel] rpm в p9

[Dmitry V. Levin]

[-- 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 --]

Re: [devel] rpm в p9

[Anton Farygin]

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

Re: [devel] rpm в p9

[Dmitry V. Levin]

[-- 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 --]

Re: [devel] rpm в p9

[Anton Farygin]

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 скрипт, который 
может это закостылять ?

Re: [devel] rpm в p9

[Dmitry V. Levin]

[-- 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 --]

Re: [devel] rpm в p9

[Anton Farygin]

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 не появится.

Re: [devel] rpm в p9

[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-й уровень графа зависимостей исходного решения, гарантий это всё равно 
не даёт.

Другими словами, при нашей воспроизводимой сборке пакетов имеем 
непредсказуемую процедуру обновления установленных решений, в том числе, 
зависимую от времени обновления.


> с промежуточными межпакетными зависимостями вида
> ".${RPM_STRICT_INTERDEPS}-NEVR".
> [...]


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] rpm в p9

[Anton Farygin]

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 у разных пакетов.