[devel] disttag и rebuild

[devel] disttag и rebuild

[Anton Farygin]

Вопрос в первую очередь к тем, кто придумывал disttag.

Хотелось бы понять, что будет с пакетом после того, как у нас появится 
p9 (на базе sisyphus) и этому пакету сделаем rebuild в task'е.

Ведь sisyphus-<таск> будет точно больше, чем p9-<таск>.

Соответственно у нас отломается обновление этого пакета ?

Или я ошибаюсь ?

Re: [devel] disttag и rebuild

[Vladimir D. Seleznev]

On Mon, Mar 25, 2019 at 02:34:07PM +0300, Anton Farygin wrote:
> Вопрос в первую очередь к тем, кто придумывал disttag.
> 
> Хотелось бы понять, что будет с пакетом после того, как у нас появится 
> p9 (на базе sisyphus) и этому пакету сделаем rebuild в task'е.
> 
> Ведь sisyphus-<таск> будет точно больше, чем p9-<таск>.
> 
> Соответственно у нас отломается обновление этого пакета ?
> Или я ошибаюсь ?

Сломается. Стройной схемы как избежать этой ситуации никто не придумал.
Но есть вопрос: насколько реальна ситуация, что пакет по каким-либо
причинам будут пересобирать в бранче.

-- 
   С уважением,
   Владимир Селезнев

Re: [devel] disttag и rebuild

[Anton Farygin]

25.03.2019 14:46, Vladimir D. Seleznev пишет:
> On Mon, Mar 25, 2019 at 02:34:07PM +0300, Anton Farygin wrote:
>> Вопрос в первую очередь к тем, кто придумывал disttag.
>>
>> Хотелось бы понять, что будет с пакетом после того, как у нас появится
>> p9 (на базе sisyphus) и этому пакету сделаем rebuild в task'е.
>>
>> Ведь sisyphus-<таск> будет точно больше, чем p9-<таск>.
>>
>> Соответственно у нас отломается обновление этого пакета ?
>> Или я ошибаюсь ?
> Сломается. Стройной схемы как избежать этой ситуации никто не придумал.
> Но есть вопрос: насколько реальна ситуация, что пакет по каким-либо
> причинам будут пересобирать в бранче.
>
100% для любых сертификаций.

Re: [devel] disttag и rebuild

[Vladimir D. Seleznev]

On Mon, Mar 25, 2019 at 02:51:48PM +0300, Anton Farygin wrote:
> 25.03.2019 14:46, Vladimir D. Seleznev пишет:
> > On Mon, Mar 25, 2019 at 02:34:07PM +0300, Anton Farygin wrote:
> >> Вопрос в первую очередь к тем, кто придумывал disttag.
> >>
> >> Хотелось бы понять, что будет с пакетом после того, как у нас появится
> >> p9 (на базе sisyphus) и этому пакету сделаем rebuild в task'е.
> >>
> >> Ведь sisyphus-<таск> будет точно больше, чем p9-<таск>.
> >>
> >> Соответственно у нас отломается обновление этого пакета ?
> >> Или я ошибаюсь ?
> > Сломается. Стройной схемы как избежать этой ситуации никто не придумал.
> > Но есть вопрос: насколько реальна ситуация, что пакет по каким-либо
> > причинам будут пересобирать в бранче.
> >
> 100% для любых сертификаций.

Насколько я понимаю, там не подразумевается обновление с прошлого бранча
на бранч. А если и подразумевается, то в прошлом бранче также все
пакеты, входящие в дистрибутивы, были пересобраны. А следовательно, в
этом случае такой проблемы нет.

-- 
   С уважением,
   Владимир Селезнев

Re: [devel] disttag и rebuild

[Anton Farygin]

25.03.2019 14:57, Vladimir D. Seleznev пишет:
> On Mon, Mar 25, 2019 at 02:51:48PM +0300, Anton Farygin wrote:
>> 25.03.2019 14:46, Vladimir D. Seleznev пишет:
>>> On Mon, Mar 25, 2019 at 02:34:07PM +0300, Anton Farygin wrote:
>>>> Вопрос в первую очередь к тем, кто придумывал disttag.
>>>>
>>>> Хотелось бы понять, что будет с пакетом после того, как у нас появится
>>>> p9 (на базе sisyphus) и этому пакету сделаем rebuild в task'е.
>>>>
>>>> Ведь sisyphus-<таск> будет точно больше, чем p9-<таск>.
>>>>
>>>> Соответственно у нас отломается обновление этого пакета ?
>>>> Или я ошибаюсь ?
>>> Сломается. Стройной схемы как избежать этой ситуации никто не придумал.
>>> Но есть вопрос: насколько реальна ситуация, что пакет по каким-либо
>>> причинам будут пересобирать в бранче.
>>>
>> 100% для любых сертификаций.
> Насколько я понимаю, там не подразумевается обновление с прошлого бранча
> на бранч. А если и подразумевается, то в прошлом бранче также все
> пакеты, входящие в дистрибутивы, были пересобраны. А следовательно, в
> этом случае такой проблемы нет.
При выпуске дистрибутивов пересобираются пакеты только в них, а не в 
репозитории.

Re: [devel] disttag и rebuild

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 288 bytes --]

On Mon, Mar 25, 2019 at 09:21:24PM +0300, Anton Farygin wrote:
[...]
> При выпуске дистрибутивов пересобираются пакеты только в них, а не в 
> репозитории.

С точки зрения репозитория всё, что собрано за пределами репозитория
-- это third party со всеми вытекающими.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] disttag и rebuild

[Anton Farygin]

25.03.2019 21:32, Dmitry V. Levin пишет:
> On Mon, Mar 25, 2019 at 09:21:24PM +0300, Anton Farygin wrote:
> [...]
>> При выпуске дистрибутивов пересобираются пакеты только в них, а не в
>> репозитории.
> С точки зрения репозитория всё, что собрано за пределами репозитория
> -- это third party со всеми вытекающими.

ну сейчас оно вполне себе вписывается в схему (на p8).

Аналогичный вопрос с локально собираемыми пакетами, в которые disttag 
просто некому сунуть.

Re: [devel] disttag и rebuild

[Vladimir D. Seleznev]

On Mon, Mar 25, 2019 at 09:35:15PM +0300, Anton Farygin wrote:
> 25.03.2019 21:32, Dmitry V. Levin пишет:
> > On Mon, Mar 25, 2019 at 09:21:24PM +0300, Anton Farygin wrote:
> > [...]
> >> При выпуске дистрибутивов пересобираются пакеты только в них, а не в
> >> репозитории.
> > С точки зрения репозитория всё, что собрано за пределами репозитория
> > -- это third party со всеми вытекающими.
> 
> ну сейчас оно вполне себе вписывается в схему (на p8).
> 
> Аналогичный вопрос с локально собираемыми пакетами, в которые disttag 
> просто некому сунуть.

hsh-rebuild --args '--define "disttag disttag"'

-- 
   С уважением,
   Владимир Селезнев

Re: [devel] disttag и rebuild

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 817 bytes --]

On Mon, Mar 25, 2019 at 09:35:15PM +0300, Anton Farygin wrote:
> 25.03.2019 21:32, Dmitry V. Levin пишет:
> > On Mon, Mar 25, 2019 at 09:21:24PM +0300, Anton Farygin wrote:
> > [...]
> >> При выпуске дистрибутивов пересобираются пакеты только в них, а не в
> >> репозитории.
> > С точки зрения репозитория всё, что собрано за пределами репозитория
> > -- это third party со всеми вытекающими.
> 
> ну сейчас оно вполне себе вписывается в схему (на p8).
> 
> Аналогичный вопрос с локально собираемыми пакетами, в которые disttag 
> просто некому сунуть.

Мне кажется, Иван в соседнем письме уже всё рассказал.
Только это почему-то реализовано пока только в бранчах.
Я предполагал, что новые фичи у нас тестируются в Сизифе
и оттуда уже переносятся в бранчи, но тут получается наоборот.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] disttag и rebuild

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 1628 bytes --]

On Mon, 25 Mar 2019, Anton Farygin wrote:

> 25.03.2019 21:32, Dmitry V. Levin пишет:
> > On Mon, Mar 25, 2019 at 09:21:24PM +0300, Anton Farygin wrote:
> > [...]
> > > При выпуске дистрибутивов пересобираются пакеты только в них, а не в
> > > репозитории.
> > С точки зрения репозитория всё, что собрано за пределами репозитория
> > -- это third party со всеми вытекающими.
> 
> ну сейчас оно вполне себе вписывается в схему (на p8).
> 
> Аналогичный вопрос с локально собираемыми пакетами, в которые disttag просто
> некому сунуть.

Если хотите вставить в пересобираемые вне сборочницы пакеты disttag, 
скажите --define 'disttag DISTTAG'.

Если нужно, чтобы они считались свежее тех, что лежат в репозитории, либо 
вообще не указывайте им disttag (тогда сравнение будет по buildtime), либо 
укажите подходящий disttag BRANCH+...

Если в репозитории все пакеты с префиксом в disttag-е, который 
лексикографически меньше (или равен) BRANCH, то будет как хочется 
(пересобранные свежее).

Сейчас, кажется, этот способ подходит для c7.1, c8.1, p8 (там нет 
disttag-ов с префиксом больше этих названий). При переключении с c7.1 на 
c7 тоже будет так.

Если в репозитории есть пакеты с большим префиксом disttag-а, то сначала 
соберите в ваш бранч rpm с --enable default_priority_distbranch, например, 
или другим способом добейтесь того, что у пользователя будет значение 
%_priority_distbranch совпадать с BRANCH, с котором вы готовите 
пересобранные пакеты.

Не знаю подробностей, как пакеты пересобираются вне сборочницы, поэтому 
даю описание в общем виде, которое каждый может применить под его случай.

-- 
Best regards,
Ivan

Re: [devel] disttag и rebuild

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 1922 bytes --]


On Mon, 25 Mar 2019, Ivan Zakharyaschev wrote:

> On Mon, 25 Mar 2019, Anton Farygin wrote:
> 
> > 25.03.2019 21:32, Dmitry V. Levin пишет:
> > > On Mon, Mar 25, 2019 at 09:21:24PM +0300, Anton Farygin wrote:
> > > [...]
> > > > При выпуске дистрибутивов пересобираются пакеты только в них, а не в
> > > > репозитории.
> > > С точки зрения репозитория всё, что собрано за пределами репозитория
> > > -- это third party со всеми вытекающими.
> > 
> > ну сейчас оно вполне себе вписывается в схему (на p8).
> > 
> > Аналогичный вопрос с локально собираемыми пакетами, в которые disttag просто
> > некому сунуть.
> 
> Если хотите вставить в пересобираемые вне сборочницы пакеты disttag, 
> скажите --define 'disttag DISTTAG'.
> 
> Если нужно, чтобы они считались свежее тех, что лежат в репозитории, либо 
> вообще не указывайте им disttag (тогда сравнение будет по buildtime), либо 
> укажите подходящий disttag BRANCH+...
> 
> Если в репозитории все пакеты с префиксом в disttag-е, который 
> лексикографически меньше (или равен) BRANCH, то будет как хочется 
> (пересобранные свежее).
> 
> Сейчас, кажется, этот способ подходит для c7.1, c8.1, p8 (там нет 
> disttag-ов с префиксом больше этих названий). При переключении с c7.1 на 
> c7 тоже будет так.

Подойдёт пустое значение для %_priority_distbranch, чтобы оно не играло 
роли при выяснении, можно ли пакет обновить. (Так rpm будет собран для 
c7.1, c8.1, p8.)

> Если в репозитории есть пакеты с большим префиксом disttag-а, то сначала 
> соберите в ваш бранч rpm с --enable default_priority_distbranch, например, 
> или другим способом добейтесь того, что у пользователя будет значение 
> %_priority_distbranch совпадать с BRANCH, с котором вы готовите 
> пересобранные пакеты.
> 
> Не знаю подробностей, как пакеты пересобираются вне сборочницы, поэтому 
> даю описание в общем виде, которое каждый может применить под его случай.
> 
> -- 
> Best regards,
> Ivan

Re: [devel] disttag и rebuild

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 609 bytes --]

On Mon, Mar 25, 2019 at 02:46:41PM +0300, Vladimir D. Seleznev wrote:
> On Mon, Mar 25, 2019 at 02:34:07PM +0300, Anton Farygin wrote:
> > Вопрос в первую очередь к тем, кто придумывал disttag.
> > 
> > Хотелось бы понять, что будет с пакетом после того, как у нас появится 
> > p9 (на базе sisyphus) и этому пакету сделаем rebuild в task'е.
> > 
> > Ведь sisyphus-<таск> будет точно больше, чем p9-<таск>.
> > 
> > Соответственно у нас отломается обновление этого пакета ?
> > Или я ошибаюсь ?
> 
> Сломается. Стройной схемы как избежать этой ситуации никто не придумал.

Разве?


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] disttag и rebuild

[Anton V. Boyarshinov]

> насколько реальна ситуация, что пакет по каким-либо
> причинам будут пересобирать в бранче.

Абсолютно реальна. Есть клиент библиотеки, мы обновляем в бранче
библиотеку и, естественно, делаем rebuild её клиенту. Упс..

Re: [devel] disttag и rebuild

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 1711 bytes --]

On Mon, 25 Mar 2019, Anton Farygin wrote:

> Вопрос в первую очередь к тем, кто придумывал disttag.
> 
> Хотелось бы понять, что будет с пакетом после того, как у нас появится p9 (на
> базе sisyphus) и этому пакету сделаем rebuild в task'е.
> 
> Ведь sisyphus-<таск> будет точно больше, чем p9-<таск>.
> 
> Соответственно у нас отломается обновление этого пакета ?
> 
> Или я ошибаюсь ?

Я сконцентрировался на rpm-4.0.4 и пока реализовал такую штуку.

Пердполагаю перенести на rpm-4.13 и собирать в p9 rpm с %def_enable 
default_priority_distbranch

$ rpm -qp /ALT/c7.1/x86_64/RPMS.classic/rpm-4.0.4-alt100.77.M70P.3.M70C.2.x86_64.rpm --lastchange
* Чт мар 14 2019 Ivan Zakharyaschev <imz@altlinux.org> 4.0.4-alt100.77.M70P.3.M70C.2
Merged 4.0.4-alt101.M80P.5.2 into c7.1:
[rpm]
- Changes in what is considered "newer" by rpm -U  pertaining to disttag
  comparison. (On the whole, to determine which package is "newer", first,
  the EVRs are compared, then the branch prefixes of the disttags if the
  disttags are present, and then the buildtimes.) The comparison of the disttags:
  + (new!) If a disttag contains no + separator (old format), the branch prefix is
    assumed to be empty (and hence "older" than any other branch prefix).
  + (new!) If the branch prefix of a disttag is equal to %_priority_distbranch
    (and it is not empty), then it is "newer" than any other ones.
  + (as before, since 4.0.4-alt101.M80P.5) The branch prefixes of disttags are
    ordered lexicographically.
- (disabled in this release; %if_enabled default_priority_distbranch)
  Give a default value to %_priority_distbranch based on the disttag
  when this package is built (the prefix before +).


-- 
Best regards,
Ivan

Re: [devel] disttag и rebuild

[Anton Farygin]

25.03.2019 16:10, Ivan Zakharyaschev пишет:
> On Mon, 25 Mar 2019, Anton Farygin wrote:
>
>> Вопрос в первую очередь к тем, кто придумывал disttag.
>>
>> Хотелось бы понять, что будет с пакетом после того, как у нас появится p9 (на
>> базе sisyphus) и этому пакету сделаем rebuild в task'е.
>>
>> Ведь sisyphus-<таск> будет точно больше, чем p9-<таск>.
>>
>> Соответственно у нас отломается обновление этого пакета ?
>>
>> Или я ошибаюсь ?
> Я сконцентрировался на rpm-4.0.4 и пока реализовал такую штуку.
>
> Пердполагаю перенести на rpm-4.13 и собирать в p9 rpm с %def_enable
> default_priority_distbranch
>
> $ rpm -qp /ALT/c7.1/x86_64/RPMS.classic/rpm-4.0.4-alt100.77.M70P.3.M70C.2.x86_64.rpm --lastchange
> * Чт мар 14 2019 Ivan Zakharyaschev <imz@altlinux.org> 4.0.4-alt100.77.M70P.3.M70C.2
> Merged 4.0.4-alt101.M80P.5.2 into c7.1:
> [rpm]
> - Changes in what is considered "newer" by rpm -U  pertaining to disttag
>    comparison. (On the whole, to determine which package is "newer", first,
>    the EVRs are compared, then the branch prefixes of the disttags if the
>    disttags are present, and then the buildtimes.) The comparison of the disttags:
>    + (new!) If a disttag contains no + separator (old format), the branch prefix is
>      assumed to be empty (and hence "older" than any other branch prefix).
>    + (new!) If the branch prefix of a disttag is equal to %_priority_distbranch
>      (and it is not empty), then it is "newer" than any other ones.
>    + (as before, since 4.0.4-alt101.M80P.5) The branch prefixes of disttags are
>      ordered lexicographically.
> - (disabled in this release; %if_enabled default_priority_distbranch)
>    Give a default value to %_priority_distbranch based on the disttag
>    when this package is built (the prefix before +).
Мне что-то вот подумалось - а чем нас не устраивал вариант -  время 
сборки  пакета + ID бранча, определяемый системно или в apt'овых 
заголовках ?

Ведь номер задания и номер подзадания - это то же самое, что время 
сборки - всегда увеличивается, обратного движения нет.

Всё, чего не хватало - это имени репозитория с понятным алгоритмом 
наследования. Это есть в disttag (первое поле).

А %if_enabled default_priority_distbranch решил бы проблему обновления с 
ветки на сизиф.

При выносе disttag на уровень apt'а получился бы аналог apt/preferences

Re: [devel] disttag и rebuild

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 3004 bytes --]

On Mon, 25 Mar 2019, Anton Farygin wrote:

> 25.03.2019 16:10, Ivan Zakharyaschev пишет:
> > On Mon, 25 Mar 2019, Anton Farygin wrote:
> >
> > > Вопрос в первую очередь к тем, кто придумывал disttag.
> > >
> > > Хотелось бы понять, что будет с пакетом после того, как у нас появится p9
> > > (на
> > > базе sisyphus) и этому пакету сделаем rebuild в task'е.
> > >
> > > Ведь sisyphus-<таск> будет точно больше, чем p9-<таск>.
> > >
> > > Соответственно у нас отломается обновление этого пакета ?
> > >
> > > Или я ошибаюсь ?
> > Я сконцентрировался на rpm-4.0.4 и пока реализовал такую штуку.
> >
> > Пердполагаю перенести на rpm-4.13 и собирать в p9 rpm с %def_enable
> > default_priority_distbranch
> >
> > $ rpm -qp
> > /ALT/c7.1/x86_64/RPMS.classic/rpm-4.0.4-alt100.77.M70P.3.M70C.2.x86_64.rpm
> > --lastchange
> > * Чт мар 14 2019 Ivan Zakharyaschev <imz@altlinux.org>
> > 4.0.4-alt100.77.M70P.3.M70C.2
> > Merged 4.0.4-alt101.M80P.5.2 into c7.1:
> > [rpm]
> > - Changes in what is considered "newer" by rpm -U  pertaining to disttag
> >    comparison. (On the whole, to determine which package is "newer", first,
> >    the EVRs are compared, then the branch prefixes of the disttags if the
> >    disttags are present, and then the buildtimes.) The comparison of the
> >    disttags:
> >    + (new!) If a disttag contains no + separator (old format), the branch
> >    prefix is
> >      assumed to be empty (and hence "older" than any other branch prefix).
> >    + (new!) If the branch prefix of a disttag is equal to
> >    %_priority_distbranch
> >      (and it is not empty), then it is "newer" than any other ones.
> >    + (as before, since 4.0.4-alt101.M80P.5) The branch prefixes of disttags
> >    are
> >      ordered lexicographically.
> > - (disabled in this release; %if_enabled default_priority_distbranch)
> >    Give a default value to %_priority_distbranch based on the disttag
> >    when this package is built (the prefix before +).
> Мне что-то вот подумалось - а чем нас не устраивал вариант -  время сборки 
> пакета + ID бранча, определяемый системно или в apt'овых заголовках ?

При решении, какой пакет "новее" ("свежее"; какое слово лучше?) для 
обновления rpm -U, весь хвост после + в disttag-е не играет роли. Только 
имя бранча до +.

> Ведь номер задания и номер подзадания - это то же самое, что время сборки -
> всегда увеличивается, обратного движения нет.

Номер задания и подзадания -- другой вариант реализовать строгие 
межподпакетные зависимости, чем ты предлагаешь (с buildtime). Кажется, 
ничем не хуже, да?

> Всё, чего не хватало - это имени репозитория с понятным алгоритмом
> наследования. Это есть в disttag (первое поле).
> 
> А %if_enabled default_priority_distbranch решил бы проблему обновления с ветки
> на сизиф.
> 
> При выносе disttag на уровень apt'а получился бы аналог apt/preferences
> 
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
> 

Re: [devel] disttag и rebuild

[Vladimir D. Seleznev]

On Mon, Mar 25, 2019 at 04:10:52PM +0300, Ivan Zakharyaschev wrote:
> On Mon, 25 Mar 2019, Anton Farygin wrote:
> 
> > Вопрос в первую очередь к тем, кто придумывал disttag.
> > 
> > Хотелось бы понять, что будет с пакетом после того, как у нас появится p9 (на
> > базе sisyphus) и этому пакету сделаем rebuild в task'е.
> > 
> > Ведь sisyphus-<таск> будет точно больше, чем p9-<таск>.
> > 
> > Соответственно у нас отломается обновление этого пакета ?
> > 
> > Или я ошибаюсь ?
> 
> Я сконцентрировался на rpm-4.0.4 и пока реализовал такую штуку.
> 
> Пердполагаю перенести на rpm-4.13 и собирать в p9 rpm с %def_enable 
> default_priority_distbranch

Зачем rpm'у default_priority_distbranch? Мне кажется, эти лишнее
усложнение. Ведь для того, чтобы это работало, надо научить ещё apt
понимать default_priority_distbranch. Иначе они не договорятся. И это
также потребует ручного переключения distbranch при dist-upgrade.

Это похоже на перенос логики apt_preferences в rpm. Лучше отдать решение
про приоритет бранчей на откуп apt'у, и, например, научить
apt-repo-tools, альтератор переключать default branch в preferences при
переключении репозиториев. Или даже лучше устанавливать вот такой
конфиг:

$ cat /etc/apt/preferences.d/origin_priority
Explanation: Always prefer packages from repository
Package: *
Pin: release o=ALT Linux Team
Pin-Priority: 1001

Тогда всегда будут в приоритете пакеты из подключенных бранчей. Что
решит проблему установки пересборанного в бранче пакета, который при
бранчевании был в Сизифе. Локально собранные пакеты можно поставить на
холд или написать для них другие приоритеты.

> $ rpm -qp /ALT/c7.1/x86_64/RPMS.classic/rpm-4.0.4-alt100.77.M70P.3.M70C.2.x86_64.rpm --lastchange
> * Чт мар 14 2019 Ivan Zakharyaschev <imz@altlinux.org> 4.0.4-alt100.77.M70P.3.M70C.2
> Merged 4.0.4-alt101.M80P.5.2 into c7.1:
> [rpm]
> - Changes in what is considered "newer" by rpm -U  pertaining to disttag
>   comparison. (On the whole, to determine which package is "newer", first,
>   the EVRs are compared, then the branch prefixes of the disttags if the
>   disttags are present, and then the buildtimes.) The comparison of the disttags:
>   + (new!) If a disttag contains no + separator (old format), the branch prefix is
>     assumed to be empty (and hence "older" than any other branch prefix).
>   + (new!) If the branch prefix of a disttag is equal to %_priority_distbranch
>     (and it is not empty), then it is "newer" than any other ones.
>   + (as before, since 4.0.4-alt101.M80P.5) The branch prefixes of disttags are
>     ordered lexicographically.
> - (disabled in this release; %if_enabled default_priority_distbranch)
>   Give a default value to %_priority_distbranch based on the disttag
>   when this package is built (the prefix before +).

-- 
   С уважением,
   Владимир Селезнев

Re: [devel] disttag и rebuild

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1499 bytes --]

On Tue, Mar 26, 2019 at 01:45:46PM +0300, Vladimir D. Seleznev wrote:
> On Mon, Mar 25, 2019 at 04:10:52PM +0300, Ivan Zakharyaschev wrote:
> > On Mon, 25 Mar 2019, Anton Farygin wrote:
> > 
> > > Вопрос в первую очередь к тем, кто придумывал disttag.
> > > 
> > > Хотелось бы понять, что будет с пакетом после того, как у нас появится p9 (на
> > > базе sisyphus) и этому пакету сделаем rebuild в task'е.
> > > 
> > > Ведь sisyphus-<таск> будет точно больше, чем p9-<таск>.
> > > 
> > > Соответственно у нас отломается обновление этого пакета ?
> > > 
> > > Или я ошибаюсь ?
> > 
> > Я сконцентрировался на rpm-4.0.4 и пока реализовал такую штуку.
> > 
> > Пердполагаю перенести на rpm-4.13 и собирать в p9 rpm с %def_enable 
> > default_priority_distbranch
> 
> Зачем rpm'у default_priority_distbranch? Мне кажется, эти лишнее
> усложнение.

Без этого rpm не заработает.

> Ведь для того, чтобы это работало, надо научить ещё apt
> понимать default_priority_distbranch. Иначе они не договорятся. И это
> также потребует ручного переключения distbranch при dist-upgrade.

Да, всё верно, при смене бранча надо менять имя целевого бранча.

> Это похоже на перенос логики apt_preferences в rpm. Лучше отдать решение
> про приоритет бранчей на откуп apt'у, и, например, научить
> apt-repo-tools, альтератор переключать default branch в preferences при
> переключении репозиториев.

Если apt и rpm будут руководствоваться разной логикой, то будет беда.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] disttag и rebuild

[Vladimir D. Seleznev]

On Tue, Mar 26, 2019 at 02:08:42PM +0300, Dmitry V. Levin wrote:
> On Tue, Mar 26, 2019 at 01:45:46PM +0300, Vladimir D. Seleznev wrote:
> > On Mon, Mar 25, 2019 at 04:10:52PM +0300, Ivan Zakharyaschev wrote:
> > > On Mon, 25 Mar 2019, Anton Farygin wrote:
> > > 
> > > > Вопрос в первую очередь к тем, кто придумывал disttag.
> > > > 
> > > > Хотелось бы понять, что будет с пакетом после того, как у нас появится p9 (на
> > > > базе sisyphus) и этому пакету сделаем rebuild в task'е.
> > > > 
> > > > Ведь sisyphus-<таск> будет точно больше, чем p9-<таск>.
> > > > 
> > > > Соответственно у нас отломается обновление этого пакета ?
> > > > 
> > > > Или я ошибаюсь ?
> > > 
> > > Я сконцентрировался на rpm-4.0.4 и пока реализовал такую штуку.
> > > 
> > > Пердполагаю перенести на rpm-4.13 и собирать в p9 rpm с %def_enable 
> > > default_priority_distbranch
> > 
> > Зачем rpm'у default_priority_distbranch? Мне кажется, эти лишнее
> > усложнение.
> 
> Без этого rpm не заработает.

Почему?

> > Ведь для того, чтобы это работало, надо научить ещё apt
> > понимать default_priority_distbranch. Иначе они не договорятся. И это
> > также потребует ручного переключения distbranch при dist-upgrade.
> 
> Да, всё верно, при смене бранча надо менять имя целевого бранча.

Это дополнительное действие, которое непонятно кто должен делать.

> > Это похоже на перенос логики apt_preferences в rpm. Лучше отдать решение
> > про приоритет бранчей на откуп apt'у, и, например, научить
> > apt-repo-tools, альтератор переключать default branch в preferences при
> > переключении репозиториев.
> 
> Если apt и rpm будут руководствоваться разной логикой, то будет беда.

У них не будет разной логики. При apt_preferences apt и rpm согласовано
будут upgrade'ить или downgrade'ить пакеты. default_priority_distbranch
как раз же привносит разную логику в поведения apt и rpm.

Мне, кстати, тот конфиг понравился: он универсальный и не привязан к
конкретному бранчу. Предлагаю рассмотреть его.

-- 
   С уважением,
   Владимир Селезнев

Re: [devel] disttag и rebuild

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 823 bytes --]

> У них не будет разной логики. При apt_preferences apt и rpm согласовано
> будут upgrade'ить или downgrade'ить пакеты. default_priority_distbranch
> как раз же привносит разную логику в поведения apt и rpm.

Просто %_priority_distbranch. default_priority_distbranch -- название 
ручки в спеке, чтобы придать ему определённое значение.

> Мне, кстати, тот конфиг понравился: он универсальный и не привязан к
> конкретному бранчу. Предлагаю рассмотреть его.

Думаю, надо протестировать apt с этим конфигом в аналогичных ситуациях, 
где у меня %_priority_distbranch тестируется.

Пока не готов оценить полностью предложение.

> 
> -- 
>    С уважением,
>    Владимир Селезнев
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] disttag и rebuild

[Anton Farygin]

26.03.2019 14:32, Ivan Zakharyaschev пишет:
>> У них не будет разной логики. При apt_preferences apt и rpm согласовано
>> будут upgrade'ить или downgrade'ить пакеты. default_priority_distbranch
>> как раз же привносит разную логику в поведения apt и rpm.
> Просто %_priority_distbranch. default_priority_distbranch -- название
> ручки в спеке, чтобы придать ему определённое значение.
>
>> Мне, кстати, тот конфиг понравился: он универсальный и не привязан к
>> конкретному бранчу. Предлагаю рассмотреть его.
> Думаю, надо протестировать apt с этим конфигом в аналогичных ситуациях,
> где у меня %_priority_distbranch тестируется.
>
> Пока не готов оценить полностью предложение.
>
Что-то в ручках я совсем запутался.

apt/preferences сейчас работают при обновлении с p8 до Sisyphus.

В принципе, будут работать и при обновлении с p9 до p9 для пакетов, 
которым сделали rebuild    ?

Но у него сейчас есть недостаток - странное сообщение о том, что часть 
пакетов при обновлении downgrad'ится, хотя на самом деле версия там не 
меняется, а меняется время сборки (ну и содержимое, естественно).

Если это починить, то зачем тогда priority_distbranch ?

Re: [devel] disttag и rebuild

[Vladimir D. Seleznev]

On Tue, Mar 26, 2019 at 02:40:55PM +0300, Anton Farygin wrote:
> 26.03.2019 14:32, Ivan Zakharyaschev пишет:
> >> У них не будет разной логики. При apt_preferences apt и rpm согласовано
> >> будут upgrade'ить или downgrade'ить пакеты. default_priority_distbranch
> >> как раз же привносит разную логику в поведения apt и rpm.
> > Просто %_priority_distbranch. default_priority_distbranch -- название
> > ручки в спеке, чтобы придать ему определённое значение.
> >
> >> Мне, кстати, тот конфиг понравился: он универсальный и не привязан к
> >> конкретному бранчу. Предлагаю рассмотреть его.
> > Думаю, надо протестировать apt с этим конфигом в аналогичных ситуациях,
> > где у меня %_priority_distbranch тестируется.
> >
> > Пока не готов оценить полностью предложение.
> >
> Что-то в ручках я совсем запутался.
> 
> apt/preferences сейчас работают при обновлении с p8 до Sisyphus.

Я немного обобщил конфиг (см. письмо ранее), что мне кажется хорошим
решением.

> В принципе, будут работать и при обновлении с p9 до p9 для пакетов, 
> которым сделали rebuild    ?

С этим новым конфигом пересобранные пакеты будут обновляться. Предлагаю
вам потестировать его, но я знаю, что они будут обновляться. И при
переключении на другой бранч те пакеты также будут обновляться.

> Но у него сейчас есть недостаток - странное сообщение о том, что часть 
> пакетов при обновлении downgrad'ится, хотя на самом деле версия там не 
> меняется, а меняется время сборки (ну и содержимое, естественно).

Благодаря лексикографическому сравнению DistTag'ов, несмотря на то, что
это хак, таких сообщений будет гораздо меньше, вплоть до полного
отсутствия. Исключения: как раз-таки пересобранные пакеты из вопроса
выше. Но в самих этих сообщениях нет ничего страшного, более того,
например, в дистрибутивах SUSE при dist-upgrade на другие бранчи
постоянно сообщается, что часть пакетов будет downgraded. Учитывая, что
у нас нет линейного порядка версий, нам надо это просто принять, как
данность.

> Если это починить, то зачем тогда priority_distbranch ?

Я тоже не понимаю зачем.

-- 
   С уважением,
   Владимир Селезнев