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