[devel] Изменения в сборочнице

[devel] Изменения в сборочнице

[Vladimir D. Seleznev]

Доброго времени суток!

Не раньше завтрашнего вечера в сборочнице произойдут следующие
изменения:

* будет запрещено копирование пакетов в бранчи;
* будет разрешена пересборка пакетов для Sisyphus без повышения релиза
пакета с помощью команды rebuild.

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

https://www.altlinux.org/Binary_package_identity_change

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

Re: [devel] Изменения в сборочнице

[Denis Medvedev]

On четверг, 30 августа 2018 г. 23:42:31 MSK Vladimir D. Seleznev wrote:
> Доброго времени суток!
> 
> Не раньше завтрашнего вечера в сборочнице произойдут следующие
> изменения:
> 
> * будет запрещено копирование пакетов в бранчи;
> * будет разрешена пересборка пакетов для Sisyphus без повышения релиза
> пакета с помощью команды rebuild.
> 
> В течении некоторое времени копирование пакетов будет невозможно, потом
> команда копирования будет приводить к пересборке пакета из исходного
> бранча в целевой. Одновременно с этим станет возможным сборка пакетов с
"Некоторого времени" - ориентировочно часы? Дни? Что будет с висящими в  test-
only и EPERM task copy?
> одинаковой эпохой:версией-релизом в разные бранчи при условии
> совпадении их исходников.
> 
> https://www.altlinux.org/Binary_package_identity_change

Re: [devel] Изменения в сборочнице

[Vladimir D. Seleznev]

On Fri, Aug 31, 2018 at 09:19:25AM +0300, Denis Medvedev wrote:
> On четверг, 30 августа 2018 г. 23:42:31 MSK Vladimir D. Seleznev wrote:
> > Доброго времени суток!
> > 
> > Не раньше завтрашнего вечера в сборочнице произойдут следующие
> > изменения:
> > 
> > * будет запрещено копирование пакетов в бранчи;
> > * будет разрешена пересборка пакетов для Sisyphus без повышения релиза
> > пакета с помощью команды rebuild.
> > 
> > В течении некоторое времени копирование пакетов будет невозможно, потом
> > команда копирования будет приводить к пересборке пакета из исходного
> > бранча в целевой. Одновременно с этим станет возможным сборка пакетов с

> "Некоторого времени" - ориентировочно часы? Дни?

Дни.

> Что будет с висящими в  test- only и EPERM task copy?

Такие сабтаски никогда не соберутся.

> > одинаковой эпохой:версией-релизом в разные бранчи при условии
> > совпадении их исходников.

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

Re: [devel] Изменения в сборочнице

[Антон Мидюков]

31.08.2018 14:26, Vladimir D. Seleznev пишет:
> On Fri, Aug 31, 2018 at 09:19:25AM +0300, Denis Medvedev wrote:
>> On четверг, 30 августа 2018 г. 23:42:31 MSK Vladimir D. Seleznev wrote:
>>> Доброго времени суток!
>>>
>>> Не раньше завтрашнего вечера в сборочнице произойдут следующие
>>> изменения:
>>>
>>> * будет запрещено копирование пакетов в бранчи;
>>> * будет разрешена пересборка пакетов для Sisyphus без повышения релиза
>>> пакета с помощью команды rebuild.
>>>
>>> В течении некоторое времени копирование пакетов будет невозможно, потом
>>> команда копирования будет приводить к пересборке пакета из исходного
>>> бранча в целевой. Одновременно с этим станет возможным сборка пакетов с
>> "Некоторого времени" - ориентировочно часы? Дни?
> Дни.
>
А долго ещё ждать? Хоть приблизительно.

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel] Изменения в сборочнице

[Vladimir D. Seleznev]

On Tue, Sep 11, 2018 at 06:35:43PM +0700, Антон Мидюков wrote:
> 31.08.2018 14:26, Vladimir D. Seleznev пишет:
> > On Fri, Aug 31, 2018 at 09:19:25AM +0300, Denis Medvedev wrote:
> >> On четверг, 30 августа 2018 г. 23:42:31 MSK Vladimir D. Seleznev wrote:
> >>> Доброго времени суток!
> >>>
> >>> Не раньше завтрашнего вечера в сборочнице произойдут следующие
> >>> изменения:
> >>>
> >>> * будет запрещено копирование пакетов в бранчи;
> >>> * будет разрешена пересборка пакетов для Sisyphus без повышения релиза
> >>> пакета с помощью команды rebuild.
> >>>
> >>> В течении некоторое времени копирование пакетов будет невозможно, потом
> >>> команда копирования будет приводить к пересборке пакета из исходного
> >>> бранча в целевой. Одновременно с этим станет возможным сборка пакетов с
> >> "Некоторого времени" - ориентировочно часы? Дни?
> > Дни.
> >
> А долго ещё ждать? Хоть приблизительно.

Решили пока не вводить эти изменения (как минимум неделю); пока
копировать можно.

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

Re: [devel] Изменения в сборочнице

[Антон Мидюков]

11.09.2018 21:54, Vladimir D. Seleznev пишет:
> On Tue, Sep 11, 2018 at 06:35:43PM +0700, Антон Мидюков wrote:
>> 31.08.2018 14:26, Vladimir D. Seleznev пишет:
>>> On Fri, Aug 31, 2018 at 09:19:25AM +0300, Denis Medvedev wrote:
>>>> On четверг, 30 августа 2018 г. 23:42:31 MSK Vladimir D. Seleznev wrote:
>>>>> Доброго времени суток!
>>>>>
>>>>> Не раньше завтрашнего вечера в сборочнице произойдут следующие
>>>>> изменения:
>>>>>
>>>>> * будет запрещено копирование пакетов в бранчи;
>>>>> * будет разрешена пересборка пакетов для Sisyphus без повышения релиза
>>>>> пакета с помощью команды rebuild.
>>>>>
>>>>> В течении некоторое времени копирование пакетов будет невозможно, потом
>>>>> команда копирования будет приводить к пересборке пакета из исходного
>>>>> бранча в целевой. Одновременно с этим станет возможным сборка пакетов с
>>>> "Некоторого времени" - ориентировочно часы? Дни?
>>> Дни.
>>>
>> А долго ещё ждать? Хоть приблизительно.
> Решили пока не вводить эти изменения (как минимум неделю); пока
> копировать можно.
Понял. Надо ловить момент.

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel] Изменения в сборочнице

[Sergey Afonin]

On Friday 31 August 2018, Vladimir D. Seleznev wrote:

> * будет запрещено копирование пакетов в бранчи;
 
Даже noarch? Смысл, например, в пересборке usb-modeswitch-data?
Или man-pages...

-- 
С уважением, Сергей Афонин.

Re: [devel] Изменения в сборочнице

[Anton V. Boyarshinov]

В Fri, 31 Aug 2018 11:17:51 +0400
Sergey Afonin <asy@altlinux.org> пишет:

> > * будет запрещено копирование пакетов в бранчи;  
Это временная мера, чтоб вводить изменения в сборочнице постепенно и,
соответственно, в случае разлома иметь меньшую поверхность поиска
проблем.

> Даже noarch? Смысл, например, в пересборке usb-modeswitch-data?
> Или man-pages...
Многие noarch пакеты содержат в себе достаточно нетривиальную процедуру
сборки. Проще и правильнее пересобирать их все, чем городить
неестественный интеллект, который будет отличать эти случаи от "мамой
клянусь, этот пакет такой простой, что его сборка не может сломаться".

Ну и повторно приведу ссылку:
https://www.altlinux.org/Binary_package_identity_change

Re: [devel] Изменения в сборочнице

[Sergey V Turchin]

On Thursday, 30 August 2018 23:42:31 MSK Vladimir D wrote:

[...]
> * будет запрещено копирование пакетов в бранчи;
%ubt рулит! ;-)

[...]

-- 
Regards, Sergey.

Re: [devel] Изменения в сборочнице

[Anton V. Boyarshinov]

On Fri, 31 Aug 2018 11:55:48 +0300 Sergey V Turchin wrote:

> > * будет запрещено копирование пакетов в бранчи;  
> %ubt рулит! ;-)
Нет, рулит https://www.altlinux.org/Binary_package_identity_change
С  ним %ubt станет не нужен (и, надеюсь, будет так или иначе истреблён)

Re: [devel] Изменения в сборочнице

[Grigory Ustinov]

31.08.2018 13:20, Anton V. Boyarshinov пишет:
> Нет, рулит https://www.altlinux.org/Binary_package_identity_change
> С ним %ubt станет не нужен (и, надеюсь, будет так или иначе истреблён) 

Готов написать робота, который будет убирать ubt-макрос из всех пакетов 
и зависимость на соответствующий пакет, после чего можно будет тихо, 
мирно удалить его из сизифа.

Re: [devel] Изменения в сборочнице

[Sergey V Turchin]

On Friday, 31 August 2018 14:09:33 MSK Grigory Ustinov wrote:
> 31.08.2018 13:20, Anton V. Boyarshinov пишет:
> > Нет, рулит https://www.altlinux.org/Binary_package_identity_change
> > С ним %ubt станет не нужен (и, надеюсь, будет так или иначе истреблён)
> 
> Готов написать робота, который будет
Будет патчить rpmbuild в < p9?

> убирать ubt-макрос из всех пакетов
> и зависимость на соответствующий пакет,
, поднимать релиз и добавлять ченжлог.

> после чего можно будет тихо,
> мирно удалить его из сизифа.
Нет. Только после того, как этот "сизиф" станет самым старым из поддерживаемых 
бранчей.

-- 
Regards, Sergey.

Re: [devel] Изменения в сборочнице

[Anton V. Boyarshinov]

On Fri, 31 Aug 2018 14:39:57 +0300 Sergey V Turchin wrote:

> On Friday, 31 August 2018 14:09:33 MSK Grigory Ustinov wrote:
> > 31.08.2018 13:20, Anton V. Boyarshinov пишет:  
> > > Нет, рулит https://www.altlinux.org/Binary_package_identity_change
> > > С ним %ubt станет не нужен (и, надеюсь, будет так или иначе истреблён)  
> > 
> > Готов написать робота, который будет  
> Будет патчить rpmbuild в < p9?
rpmbuild в бранчах < p9 будет запатчен в ближайшее время. Собственно,
это одна из причин, по которой "новое" копирование не вводится прямо
сегодня.

> 
> > убирать ubt-макрос из всех пакетов
> > и зависимость на соответствующий пакет,  
> , поднимать релиз и добавлять ченжлог.
> 
> > после чего можно будет тихо,
> > мирно удалить его из сизифа.  
> Нет. Только после того, как этот "сизиф" станет самым старым из поддерживаемых 
> бранчей.
> 
> -- 
> Regards, Sergey.
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] Изменения в сборочнице

[Sergey V Turchin]

On Friday, 31 August 2018 14:57:10 MSK Anton V wrote:

[...]
> rpmbuild в бранчах < p9 будет запатчен в ближайшее время.
Класс! Я даже не надеялся.

[...]

-- 
Regards, Sergey.

[devel] робот, который будет убирать ubt-макрос (was: Изменения в сборочнице)

[Sergey V Turchin]

On Friday, 31 August 2018 14:09:33 MSK Grigory Ustinov wrote:

[...]
> Готов написать робота, который будет убирать ubt-макрос
diff на spec от kde5-k3b в студию! ;-)

[...]

-- 
Regards, Sergey.

Re: [devel] робот, который будет убирать ubt-макрос

[Grigory Ustinov]

On 31.08.2018 15:34, Sergey V Turchin wrote:
> diff на spec от kde5-k3b в студию! ;-) 

Робот на то и робот, что он делает только механическую работу с 
подавляющим большинством тривиальных случаев. Очевидно, что найдутся 
десятки пакетов, которые придётся оперировать вручную.

Re: [devel] робот, который будет убирать ubt-макрос

[Sergey V Turchin]

On Friday, 31 August 2018 18:44:39 MSK Grigory Ustinov wrote:
> On 31.08.2018 15:34, Sergey V Turchin wrote:
> > diff на spec от kde5-k3b в студию! ;-)
> 
> Робот на то и робот, что он делает только механическую работу с
> подавляющим большинством тривиальных случаев. Очевидно, что найдутся
> десятки пакетов, которые придётся оперировать вручную.
Покажи diff вручную. ;-)

-- 
Regards, Sergey.

Re: [devel] Изменения в сборочнице

[Dmitry V. Levin]

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

On Fri, Aug 31, 2018 at 02:09:33PM +0300, Grigory Ustinov wrote:
> 31.08.2018 13:20, Anton V. Boyarshinov пишет:
> > Нет, рулит https://www.altlinux.org/Binary_package_identity_change
> > С ним %ubt станет не нужен (и, надеюсь, будет так или иначе истреблён) 
> 
> Готов написать робота, который будет убирать ubt-макрос из всех пакетов 
> и зависимость на соответствующий пакет, после чего можно будет тихо, 
> мирно удалить его из сизифа.

Проблема в том, что когда придёт время удалить этот макрос, просто так
удалить его из спека не получится, поскольку релиз сразу станет меньше.
По той же причине не получится просто заменить значение этого макроса на %nil.


-- 
ldv

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

Re: [devel] Изменения в сборочнице

[Grigory Ustinov]

On 31.08.2018 15:41, Dmitry V. Levin wrote:
>
> Проблема в том, что когда придёт время удалить этот макрос, просто так
> удалить его из спека не получится, поскольку релиз сразу станет меньше.
> По той же причине не получится просто заменить значение этого макроса на %nil.
>
А сделать +1 к релизу?

Re: [devel] Изменения в сборочнице

[Антон Мидюков]

31.08.2018 22:46, Grigory Ustinov пишет:
> On 31.08.2018 15:41, Dmitry V. Levin wrote:
>>
>> Проблема в том, что когда придёт время удалить этот макрос, просто так
>> удалить его из спека не получится, поскольку релиз сразу станет меньше.
>> По той же причине не получится просто заменить значение этого макроса 
>> на %nil.
>>
> А сделать +1 к релизу?
А может просто заменить %ubt на S1 в спеке? Релиз будет тот же.

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel] Изменения в сборочнице

[Sergey V Turchin]

On Friday, 31 August 2018 13:20:37 MSK Anton V wrote:
> On Fri, 31 Aug 2018 11:55:48 +0300 Sergey V Turchin wrote:
> > > * будет запрещено копирование пакетов в бранчи;
> > 
> > %ubt рулит! ;-)
> 
> Нет, рулит https://www.altlinux.org/Binary_package_identity_change
> С  ним %ubt станет не нужен 
Не станет до тех пор, пока есть необходимость собирать пакеты в бранчи, где 
этого нет.

> (и, надеюсь, будет так
Я тоже.

> или иначе
На это не надейтесь. ;-)

> истреблён)

-- 
Regards, Sergey.

[devel] Binary package identity (was: Изменения в сборочнице)

[Sergey V Turchin]

On Friday, 31 August 2018 13:20:37 MSK Anton V wrote:
> On Fri, 31 Aug 2018 11:55:48 +0300 Sergey V Turchin wrote:
> > > * будет запрещено копирование пакетов в бранчи;
> > 
> > %ubt рулит! ;-)
> 
> Нет, рулит https://www.altlinux.org/Binary_package_identity_change
Можно ли будет сделать конструкцию, подобную
%if_ver_gt %ubt_id M90
	# this branch >= 9
	BuildRequires: newfeature-devel
%endif
(1-й макрос из http://bugs.altlinux.org/6010)
?

> С  ним %ubt станет не нужен
Если можно, то да.

-- 
Regards, Sergey.

Re: [devel] Binary package identity (was: Изменения в сборочнице)

[Vladimir D. Seleznev]

On Fri, Aug 31, 2018 at 03:14:30PM +0300, Sergey V Turchin wrote:
> On Friday, 31 August 2018 13:20:37 MSK Anton V wrote:
> > On Fri, 31 Aug 2018 11:55:48 +0300 Sergey V Turchin wrote:
> > > > * будет запрещено копирование пакетов в бранчи;
> > > 
> > > %ubt рулит! ;-)
> > 
> > Нет, рулит https://www.altlinux.org/Binary_package_identity_change
> Можно ли будет сделать конструкцию, подобную
> %if_ver_gt %ubt_id M90
> 	# this branch >= 9
> 	BuildRequires: newfeature-devel
> %endif
> (1-й макрос из http://bugs.altlinux.org/6010)
> ?
> 
> > С  ним %ubt станет не нужен
> Если можно, то да.

Можно будет делать проверку на %distribution.

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

Re: [devel] Binary package identity (was: Изменения в сборочнице)

[Sergey V Turchin]

On Friday, 31 August 2018 16:05:20 MSK Vladimir D wrote:

[...]
> Можно будет делать проверку на %distribution.
$ rpm --eval %distribution
ALT
Что я тут проверю? :-)

-- 
Regards, Sergey.

Re: [devel] Binary package identity (was: Изменения в сборочнице)

[Vladimir D. Seleznev]

On Fri, Aug 31, 2018 at 04:14:34PM +0300, Sergey V Turchin wrote:
> On Friday, 31 August 2018 16:05:20 MSK Vladimir D wrote:
> 
> [...]
> > Можно будет делать проверку на %distribution.
> $ rpm --eval %distribution
> ALT
> Что я тут проверю? :-)

В %distribution после обновление сборочницы будет записываться ALT
$branch.

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

Re: [devel] Binary package identity (was: Изменения в сборочнице)

[Sergey V Turchin]

On Friday, 31 August 2018 16:37:04 MSK Vladimir D wrote:
> On Fri, Aug 31, 2018 at 04:14:34PM +0300, Sergey V Turchin wrote:
> > On Friday, 31 August 2018 16:05:20 MSK Vladimir D wrote:
> > 
> > [...]
> > 
> > > Можно будет делать проверку на %distribution.
> > 
> > $ rpm --eval %distribution
> > ALT
> > Что я тут проверю? :-)
> 
> В %distribution после обновление сборочницы будет записываться ALT
> $branch.
Так, можно увидеть аналог конструкции
%if_ver_gteq %ubt_id M90
	# if current branch >= 9
    BuildRequires: newfeature-devel
%endif
?

P.S.
"Со дня на день" от boyarsh@alt значит, что все макросы и значения уже 
известны.

-- 
Regards, Sergey.

Re: [devel] Изменения в сборочнице

[Alexey Tourbin]

2018-08-30 23:42 GMT+03:00 Vladimir D. Seleznev <vseleznv@altlinux.org>:
> Доброго времени суток!
>
> Не раньше завтрашнего вечера в сборочнице произойдут следующие
> изменения:
>
> * будет запрещено копирование пакетов в бранчи;
> * будет разрешена пересборка пакетов для Sisyphus без повышения релиза
> пакета с помощью команды rebuild.

А почему будет запрещено копировать пакеты в бранчи?  Потому что были
случаи, что скопированные пакеты не работают?  Но ведь целый класс
пакетов, таких как 0ad-data.noarch, иммьюн к особенностям бранчей.  Ну
и знаете, бывали случаи, что и собранные в родной бранч пакеты не
работают. (Помню,  во время сборки кончилось место на диске, и у
Виталика Кузнецова собралась Самба с утранкейтеным бинариком. В самом
конце его зарезал bad_elf_symbols. Но пасаран!)

Другими словами, плохие линии аргументации опираются на anecdotal
evidence.  Типа, а знаете что бывает?  Один мужик ночью вышел на
улицу, а там НЛО прилетело и его забрало.  Поэтому не надо по ночам
шастать по улице.

А также мне не нравится идея, чтобы в пакет прибивать гвоздями
информацию, для какого бранча он собран. Типа теперь это будет не
просто просто пакет coreutils, а пакет coreuilts (горе-мыслитель
поднимает палец в воздух!) предназначенный для дистрибутива GOMIX 8
СП.  Такая телеология, кто для чего предназначен, демонстрирует
ментальную слабость в отношении сложных систем, неспособность описать
их работу на чуть более низком предметном уровне.

(Идея вклчать суффикс *.G80SP.* в название пакета мне тоже не очень нравится.)

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

Re: [devel] Изменения в сборочнице

[Vladimir D. Seleznev]

On Mon, Sep 03, 2018 at 04:38:22AM +0300, Alexey Tourbin wrote:
> 2018-08-30 23:42 GMT+03:00 Vladimir D. Seleznev <vseleznv@altlinux.org>:
> > Доброго времени суток!
> >
> > Не раньше завтрашнего вечера в сборочнице произойдут следующие
> > изменения:
> >
> > * будет запрещено копирование пакетов в бранчи;
> > * будет разрешена пересборка пакетов для Sisyphus без повышения релиза
> > пакета с помощью команды rebuild.
> 
> А почему будет запрещено копировать пакеты в бранчи?  Потому что были
> случаи, что скопированные пакеты не работают?  Но ведь целый класс
> пакетов, таких как 0ad-data.noarch, иммьюн к особенностям бранчей.

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

> Ну и знаете, бывали случаи, что и собранные в родной бранч пакеты не
> работают. (Помню,  во время сборки кончилось место на диске, и у
> Виталика Кузнецова собралась Самба с утранкейтеным бинариком. В самом
> конце его зарезал bad_elf_symbols. Но пасаран!)
> 
> Другими словами, плохие линии аргументации опираются на anecdotal
> evidence.  Типа, а знаете что бывает?  Один мужик ночью вышел на
> улицу, а там НЛО прилетело и его забрало.  Поэтому не надо по ночам
> шастать по улице.

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

> А также мне не нравится идея, чтобы в пакет прибивать гвоздями
> информацию, для какого бранча он собран.

Чем?

> Типа теперь это будет не
> просто просто пакет coreutils, а пакет coreuilts (горе-мыслитель
> поднимает палец в воздух!) предназначенный для дистрибутива GOMIX 8
> СП.  Такая телеология, кто для чего предназначен, демонстрирует
> ментальную слабость в отношении сложных систем, неспособность описать
> их работу на чуть более низком предметном уровне.

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

> (Идея вклчать суффикс *.G80SP.* в название пакета мне тоже не очень нравится.)

Никакие дополнительные суффиксы не будут включены в название пакетов.

> Надо было протоколировать все неочевидные случаи нарушения
> работоспособности после копирования и докапываться до причины, что там
> произошло, и дальше думать, как вынести релевантную информацию в
> зависимость у пакета.  Надо делать зависимости более достаточными в
> плане описания работоспособности, а не искусственно сегрегировать
> пакеты по предначертанному признаку.

Если бы это было возможно в общем случае. Вы способны формализовать, что
такое работоспособный пакет?

-- 
   With best regards,
   Vladimir D. Seleznev

Re: [devel] Изменения в сборочнице

[Anton Farygin]

03.09.2018 10:00, Vladimir D. Seleznev пишет:
>> (Идея вклчать суффикс *.G80SP.* в название пакета мне тоже не очень нравится.)
> Никакие дополнительные суффиксы не будут включены в название пакетов.
>
И это мне совсем не нравится. Как визуально отличать пакеты, собранные 
для разных бранчей ?

Re: [devel] Изменения в сборочнице

[Alexey Tourbin]

2018-09-03 10:00 GMT+03:00 Vladimir D. Seleznev <vseleznv@altlinux.org>:
> On Mon, Sep 03, 2018 at 04:38:22AM +0300, Alexey Tourbin wrote:
>> 2018-08-30 23:42 GMT+03:00 Vladimir D. Seleznev <vseleznv@altlinux.org>:
>> > Доброго времени суток!
>> >
>> > Не раньше завтрашнего вечера в сборочнице произойдут следующие
>> > изменения:
>> >
>> > * будет запрещено копирование пакетов в бранчи;
>> > * будет разрешена пересборка пакетов для Sisyphus без повышения релиза
>> > пакета с помощью команды rebuild.
>>
>> А почему будет запрещено копировать пакеты в бранчи?  Потому что были
>> случаи, что скопированные пакеты не работают?  Но ведь целый класс
>> пакетов, таких как 0ad-data.noarch, иммьюн к особенностям бранчей.
>
> Это правда, но мне видится корректным решением собирать пакеты в родном
> окружении, нежели копировать из чужого бранча. А если такой иммьюнный
> пакет не соберётся, то это явный признак, что что-то идёт не так.

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

И все же как стратегия минимизации риска запрет копирования имеет
некоторый смысл. Но это крайняя мера, которая проистекает из крайнего
незнания и крайнего риска. Животное когда слышит, что в кустах что-то
шуршит, то оно не знает, притаился ли там лев, или же это просто
ветерок дует.  Но с точки зрения выживания ему гораздо выгоднее
убежать, даже если это всего лишь ветерок (по-научному это называется
risk aversion as an evolutionary adaptation и т.п.).  То есть еще и
цена ошибки сюда примешивается, в духе Pascal's wager. Но более
осмысленное управление рисками появляется только по мере прогресса
знания. А из одного только незнания ничего более умного, кроме как
бежать и запрещать, извлечь нельзя.

>> Ну и знаете, бывали случаи, что и собранные в родной бранч пакеты не
>> работают. (Помню,  во время сборки кончилось место на диске, и у
>> Виталика Кузнецова собралась Самба с утранкейтеным бинариком. В самом
>> конце его зарезал bad_elf_symbols. Но пасаран!)
>>
>> Другими словами, плохие линии аргументации опираются на anecdotal
>> evidence.  Типа, а знаете что бывает?  Один мужик ночью вышел на
>> улицу, а там НЛО прилетело и его забрало.  Поэтому не надо по ночам
>> шастать по улице.
>
> А ещё бывают формально собранные корректно, без внешних вредящих
> факторов, но не работающие по самым разным причинам, которые наши
> проверка не отлавливают, и отловить которые в общем случае невозможно.
> Но эти всё не относится к копированию и не говорят в пользу того, что
> копирование пакетов — хорошая практика.

Надо было систематизировать все случаи неработоспособности пакетов
после копирования. Без этого получается решение, основанное на
незнании.

>> А также мне не нравится идея, чтобы в пакет прибивать гвоздями
>> информацию, для какого бранча он собран.
>
> Чем?

Ох... Ну я ставлю под сомнение "стабильный бранч" как первичное
понятие. Это понятие вторичное, маркетинговое и подражательное Ред
Хату.  А первичное понятие - это пакет coreutils, в нем лежит
программа /bin/cat, которая слинкована с libc.so.6 и т.д.
Спрашивается, к какому бранчу по классификации Линнея этот пакет
относится, к ALT SP 7 или к GOMIX 8?  Куда он направлялся своим
сборщиком, и где его жизненное предназначение?  Телеология на марше.

Представьте на секунду, что есть дистрибутив, который состоит из
"голых" пакетов %name-tar.gz, и устанавливаются они командой (cd / &&
tar xf).  Замнем также некоторые несущественные детали.  В таком
дистрибутиве действительно единственной стратегией является жесткая
сегрегация подходящих и не подходящих под этот дистрибутив пакетов,
поскольку понятия информации о пакете нету, и восстановить
метаинформацию никак нельзя. Надо брать пакеты из правильной папки, в
которой они лежат! А иначе all bets are off.

К понятию "стабильный бранч" есть много других претензий, и я даже не
знаю, стоит ли начинать и ввязываться в этот разговор.  Например, Ред
Хат в мошенническим образом (по нашим понятиям) поставляет в свои
старые дистрибутивы новый тулчейн (он называется devtoolset-7, и
насколько я понял, он даже не собирается из исходников, а откуда-то
готовые бинарики копируются).  Потому что дистрибутив со старым
тулчейном быстро девальвируется по объективным рыночным к нему
ожиданиям. Андрей Черепанов в телеграме кажется жаловался, что новый
софт часто не удается собрать в старые бранчи из-за старого
компилятора, прямо хоть новый gcc.tar.gz в firefox.src.rpm
заворачивай. Так. А тогда собственно возникает вопрос о ценности
бранча. В чем вообще ценность этого вашего стабильного дистрибутива
состоит, если в нем gcc.tar.gz нужно всегда иметь под рукой? Вопрос
этот я боюсь в конечном счете не технический.

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

Ну вот есть какая идея. При сборке пакета же выполняется "make test".
Надо научиться так перепаковывать этот "make test", чтобы он мог
выполняться в любой момент супротив установленного пакета в
хост-системе, а не токмо в дереве сборки. Тогда работоспособность
"make test" - это хороший признак работоспособности пакета в новом
окружении.

Но конечно это нельзя всё поставить на поток к завтрашнему дню.
Наследие sourсe-based дистрибутивов тянет нас назад, и еще очень долго
будет тянуть.

Re: [devel] Изменения в сборочнице

[Dmitry V. Levin]

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

On Mon, Sep 03, 2018 at 11:48:04AM +0300, Alexey Tourbin wrote:
> 2018-09-03 10:00 GMT+03:00 Vladimir D. Seleznev <vseleznv@altlinux.org>:
> > On Mon, Sep 03, 2018 at 04:38:22AM +0300, Alexey Tourbin wrote:
> >> 2018-08-30 23:42 GMT+03:00 Vladimir D. Seleznev <vseleznv@altlinux.org>:
> >> > Доброго времени суток!
> >> >
> >> > Не раньше завтрашнего вечера в сборочнице произойдут следующие
> >> > изменения:
> >> >
> >> > * будет запрещено копирование пакетов в бранчи;
> >> > * будет разрешена пересборка пакетов для Sisyphus без повышения релиза
> >> > пакета с помощью команды rebuild.
> >>
> >> А почему будет запрещено копировать пакеты в бранчи?  Потому что были
> >> случаи, что скопированные пакеты не работают?  Но ведь целый класс
> >> пакетов, таких как 0ad-data.noarch, иммьюн к особенностям бранчей.
> >
> > Это правда, но мне видится корректным решением собирать пакеты в родном
> > окружении, нежели копировать из чужого бранча. А если такой иммьюнный
> > пакет не соберётся, то это явный признак, что что-то идёт не так.
> 
> Ну значит некоторые пакеты все же копировать можно, но поскольку мы
> наверняка не знаем, какие именно можно, а какие нельзя, то проще
> запретить.

Я считаю, что копировать можно (и нужно!) те и только те пакеты, которые
в результате сборки существенно не меняются, например, у которых
не меняется (виртуальный) RPMTAG_IDENTITY.

Но для того, чтобы определить, можно ли пакет скопировать,
его придётся предварительно собрать.

> Этот принцип действия называется "как бы чего не вышло", и
> он мне не нравится тем, что отметает все рациональные построения по
> части зависимостей как недостаточные. Кстати, и термин "родное
> окружение" - он ведь не чисто технический, а с элементом метафоры.
> Неохота досконально разбираться, что там происходит в каждом отдельном
> случае, какие бывают классы случаев и т.п. Проще окрестить это
> неродной средой и вздохнуть с облегчением.

Не знаю, что такое "родное окружение", может, это когда родные окружают.

С точки зрения воспроизводимости результата сборки пакет следует собирать
в текущем окружении.  Это требование можно ослабить, если пакет, собранный
в каком-то другом окружении, существенно не отличается от пакета,
собранного в текущем окружении.


-- 
ldv

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

Re: [devel] Изменения в сборочнице

[Paul Wolneykien]

03.09.2018 11:48, Alexey Tourbin пишет:
> Ох... Ну я ставлю под сомнение "стабильный бранч" как первичное
> понятие. Это понятие вторичное, маркетинговое и подражательное Ред
> Хату.  А первичное понятие - это пакет coreutils, в нем лежит
> программа /bin/cat, которая слинкована с libc.so.6 и т.д.
> Спрашивается, к какому бранчу по классификации Линнея этот пакет
> относится, к ALT SP 7 или к GOMIX 8?  Куда он направлялся своим
> сборщиком, и где его жизненное предназначение?  Телеология на марше.

  Алексей, а почему бы не посмотреть на это, как на _происхождение_
пакета, а не на его "предназначение"?

  Насколько я понял, в пакете будет записано:

    * Кто собирал? Иванов.
    * Когда собирал? В четверг.
    * Где собирал? Сборочница № 1.
    * Какие пакеты были доступны для сборки? Ветка "ALT P8" (это и есть
новый пункт в информации о пакете).

  Короче говоря, пакет собирался на базе ветки "ALT P8", причём такой,
какой она была в четверг.

  Эта информация, скорее помогает ответить на вопрос "Откуда взялся этот
пакет?" нежели на вопрос "Какого предназначение этого пакета?", который,
на мой взгляд, звучит довольно странно.

  Если уж ставить вопрос о "предназначении" пакетов (хотя и не ясно для
чего его ставить), то начинать нужно вот отсюда:

    ssh girar task new p8

  Может быть уже эта команда вызывает у вас сомнения?

Re: [devel] Изменения в сборочнице

[Michael Shigorin]

On Tue, Sep 04, 2018 at 04:00:16PM +0300, Paul Wolneykien wrote:
> * Какие пакеты были доступны для сборки? Ветка "ALT P8"

Напрашивается номер задания, если именно в таком контексте -- но:

- эта информация удобна для воспроизведения, но не для
  классификации (как в том анекдоте про путешествующих на шаре
  и математика на земле);

- эта информация обычно недоступна во время подготовки пакета
  (если не сказать заранее task new и не засунуть именно туда),
  хотя и безусловно доступна ко времени его сборки сборочницей.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] Изменения в сборочнице

[Vladimir D. Seleznev]

On Mon, Sep 03, 2018 at 11:48:04AM +0300, Alexey Tourbin wrote:
> 2018-09-03 10:00 GMT+03:00 Vladimir D. Seleznev <vseleznv@altlinux.org>:
> > On Mon, Sep 03, 2018 at 04:38:22AM +0300, Alexey Tourbin wrote:
> >> 2018-08-30 23:42 GMT+03:00 Vladimir D. Seleznev <vseleznv@altlinux.org>:
> >> > Доброго времени суток!
> >> >
> >> > Не раньше завтрашнего вечера в сборочнице произойдут следующие
> >> > изменения:
> >> >
> >> > * будет запрещено копирование пакетов в бранчи;
> >> > * будет разрешена пересборка пакетов для Sisyphus без повышения релиза
> >> > пакета с помощью команды rebuild.
> >>
> >> А почему будет запрещено копировать пакеты в бранчи?  Потому что были
> >> случаи, что скопированные пакеты не работают?  Но ведь целый класс
> >> пакетов, таких как 0ad-data.noarch, иммьюн к особенностям бранчей.
> >
> > Это правда, но мне видится корректным решением собирать пакеты в родном
> > окружении, нежели копировать из чужого бранча. А если такой иммьюнный
> > пакет не соберётся, то это явный признак, что что-то идёт не так.
> 
> Ну значит некоторые пакеты все же копировать можно, но поскольку мы
> наверняка не знаем, какие именно можно, а какие нельзя, то проще
> запретить. Этот принцип действия называется "как бы чего не вышло", и
> он мне не нравится тем, что отметает все рациональные построения по
> части зависимостей как недостаточные. Кстати, и термин "родное
> окружение" - он ведь не чисто технический, а с элементом метафоры.
> Неохота досконально разбираться, что там происходит в каждом отдельном
> случае, какие бывают классы случаев и т.п. Проще окрестить это
> неродной средой и вздохнуть с облегчением.
> 
> И все же как стратегия минимизации риска запрет копирования имеет
> некоторый смысл. Но это крайняя мера, которая проистекает из крайнего
> незнания и крайнего риска. Животное когда слышит, что в кустах что-то
> шуршит, то оно не знает, притаился ли там лев, или же это просто
> ветерок дует.  Но с точки зрения выживания ему гораздо выгоднее
> убежать, даже если это всего лишь ветерок (по-научному это называется
> risk aversion as an evolutionary adaptation и т.п.).  То есть еще и
> цена ошибки сюда примешивается, в духе Pascal's wager. Но более
> осмысленное управление рисками появляется только по мере прогресса
> знания. А из одного только незнания ничего более умного, кроме как
> бежать и запрещать, извлечь нельзя.

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

> >> Ну и знаете, бывали случаи, что и собранные в родной бранч пакеты не
> >> работают. (Помню,  во время сборки кончилось место на диске, и у
> >> Виталика Кузнецова собралась Самба с утранкейтеным бинариком. В самом
> >> конце его зарезал bad_elf_symbols. Но пасаран!)
> >>
> >> Другими словами, плохие линии аргументации опираются на anecdotal
> >> evidence.  Типа, а знаете что бывает?  Один мужик ночью вышел на
> >> улицу, а там НЛО прилетело и его забрало.  Поэтому не надо по ночам
> >> шастать по улице.
> >
> > А ещё бывают формально собранные корректно, без внешних вредящих
> > факторов, но не работающие по самым разным причинам, которые наши
> > проверка не отлавливают, и отловить которые в общем случае невозможно.
> > Но эти всё не относится к копированию и не говорят в пользу того, что
> > копирование пакетов — хорошая практика.
> 
> Надо было систематизировать все случаи неработоспособности пакетов
> после копирования. Без этого получается решение, основанное на
> незнании.
> 
> >> А также мне не нравится идея, чтобы в пакет прибивать гвоздями
> >> информацию, для какого бранча он собран.
> >
> > Чем?
> 
> Ох... Ну я ставлю под сомнение "стабильный бранч" как первичное
> понятие. Это понятие вторичное, маркетинговое и подражательное Ред
> Хату.  А первичное понятие - это пакет coreutils, в нем лежит
> программа /bin/cat, которая слинкована с libc.so.6 и т.д.
> Спрашивается, к какому бранчу по классификации Линнея этот пакет
> относится, к ALT SP 7 или к GOMIX 8?  Куда он направлялся своим
> сборщиком, и где его жизненное предназначение?  Телеология на марше.

Согласен с manowar@, это информация не о предназначении пакета, а о его
происхождении. Она ровном счётом ни на что не влияет, равно как и,
например, buildhost. Назначение этого тега информационное.

> Представьте на секунду, что есть дистрибутив, который состоит из
> "голых" пакетов %name-tar.gz, и устанавливаются они командой (cd / &&
> tar xf).  Замнем также некоторые несущественные детали.  В таком
> дистрибутиве действительно единственной стратегией является жесткая
> сегрегация подходящих и не подходящих под этот дистрибутив пакетов,
> поскольку понятия информации о пакете нету, и восстановить
> метаинформацию никак нельзя. Надо брать пакеты из правильной папки, в
> которой они лежат! А иначе all bets are off.
> 
> К понятию "стабильный бранч" есть много других претензий, и я даже не
> знаю, стоит ли начинать и ввязываться в этот разговор.  Например, Ред
> Хат в мошенническим образом (по нашим понятиям) поставляет в свои
> старые дистрибутивы новый тулчейн (он называется devtoolset-7, и
> насколько я понял, он даже не собирается из исходников, а откуда-то
> готовые бинарики копируются).  Потому что дистрибутив со старым
> тулчейном быстро девальвируется по объективным рыночным к нему
> ожиданиям. Андрей Черепанов в телеграме кажется жаловался, что новый
> софт часто не удается собрать в старые бранчи из-за старого
> компилятора, прямо хоть новый gcc.tar.gz в firefox.src.rpm
> заворачивай. Так. А тогда собственно возникает вопрос о ценности
> бранча. В чем вообще ценность этого вашего стабильного дистрибутива
> состоит, если в нем gcc.tar.gz нужно всегда иметь под рукой? Вопрос
> этот я боюсь в конечном счете не технический.
> 
> >> Надо было протоколировать все неочевидные случаи нарушения
> >> работоспособности после копирования и докапываться до причины, что там
> >> произошло, и дальше думать, как вынести релевантную информацию в
> >> зависимость у пакета.  Надо делать зависимости более достаточными в
> >> плане описания работоспособности, а не искусственно сегрегировать
> >> пакеты по предначертанному признаку.
> >
> > Если бы это было возможно в общем случае. Вы способны формализовать, что
> > такое работоспособный пакет?
> 
> Ну вот есть какая идея. При сборке пакета же выполняется "make test".
> Надо научиться так перепаковывать этот "make test", чтобы он мог
> выполняться в любой момент супротив установленного пакета в
> хост-системе, а не токмо в дереве сборки. Тогда работоспособность
> "make test" - это хороший признак работоспособности пакета в новом
> окружении.

Мысль интересная, но далеко не у всех пакетов есть тесты, и не все тесты
обладают достаточным покрытием. Наверное, можно генерировать
какие-нибудь %name-checkpackage, в которые записывать скрипт с
содержимым секции %check, и выделить для них отдельную компоненту. Но
сходу непонятно, когда надо запускать эти скрипты. После сборки каждого
пакета — слишком дорого. Можно периодически на текущем состоянии
репозиториев.

> Но конечно это нельзя всё поставить на поток к завтрашнему дню.
> Наследие sourсe-based дистрибутивов тянет нас назад, и еще очень долго
> будет тянуть.

А о каком именно наследии вы говорите?

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

Re: [devel] Изменения в сборочнице

[Alexey V. Vissarionov]

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

On 2018-10-08 20:44:24 +0300, Vladimir D. Seleznev wrote:

 >>>> А также мне не нравится идея, чтобы в пакет прибивать гвоздями
 >>>> информацию, для какого бранча он собран.
 >>> Чем?
 >> Ох... Ну я ставлю под сомнение "стабильный бранч" как первичное
 >> понятие. Это понятие вторичное, маркетинговое и подражательное
 >> Ред Хату. А первичное понятие - это пакет coreutils, в нем лежит
 >> программа /bin/cat, которая слинкована с libc.so.6 и т.д.

А если s/для чего собран/на основе чего был собран/ ?

 >> Спрашивается, к какому бранчу по классификации Линнея этот
 >> пакет относится, к ALT SP 7 или к GOMIX 8? Куда он направлялся
 >> своим сборщиком, и где его жизненное предназначение? Телеология
 >> на марше.
 > Согласен с manowar@, это информация не о предназначении пакета, а
 > о его происхождении. Она ровном счётом ни на что не влияет, равно
 > как и, например, buildhost. Назначение этого тега информационное.

Кстати, в %buildhost можно напихать кучу дополнительной информации о
пакете и обстоятельствах его сборки...


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

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

Re: [devel] Изменения в сборочнице

[Sergey Afonin]

On Monday 03 September 2018, Vladimir D. Seleznev wrote:

> > А почему будет запрещено копировать пакеты в бранчи?  Потому что были
> > случаи, что скопированные пакеты не работают?  Но ведь целый класс
> > пакетов, таких как 0ad-data.noarch, иммьюн к особенностям бранчей.
> 
> Это правда, но мне видится корректным решением собирать пакеты в родном
> окружении,

Вот как раз с 0ad-data.noarch. Он 669MB. Если скопировать, то это просто
хардлинк без увеличения занимаемого места, а если пересобрать, это минус
669MB. Или считается, что HDD нынче безразмерные?

-- 
С уважением, Сергей Афонин.

Re: [devel] Изменения в сборочнице

[Sergey Afonin]

On Monday 03 September 2018, Sergey Afonin wrote:

> это минус 669MB. Или считается, что HDD нынче безразмерные?

И, даже, *2, так как ещё и src.rpm: 669MB - src.rpm, 671 MB - noarch.rpm.

-- 
С уважением, Сергей Афонин.

Re: [devel] Изменения в сборочнице

[Yuri Sedunov]

В Чт, 30/08/2018 в 23:42 +0300, Vladimir D. Seleznev пишет:
> Доброго времени суток!
> 
> Не раньше завтрашнего вечера в сборочнице произойдут следующие
> изменения:
> 
> * будет запрещено копирование пакетов в бранчи;
> * будет разрешена пересборка пакетов для Sisyphus без повышения
> релиза
> пакета с помощью команды rebuild.

Плохо работает ваш rebuild.
http://git.altlinux.org/tasks/215328/logs/events.3.1.log

-- 
Yuri N. Sedunov

Re: [devel] Изменения в сборочнице

[Vladimir D. Seleznev]

On Mon, Oct 22, 2018 at 09:52:03AM +0300, Yuri Sedunov wrote:
> В Чт, 30/08/2018 в 23:42 +0300, Vladimir D. Seleznev пишет:
> > Доброго времени суток!
> > 
> > Не раньше завтрашнего вечера в сборочнице произойдут следующие
> > изменения:
> > 
> > * будет запрещено копирование пакетов в бранчи;
> > * будет разрешена пересборка пакетов для Sisyphus без повышения
> > релиза
> > пакета с помощью команды rebuild.
> 
> Плохо работает ваш rebuild.
> http://git.altlinux.org/tasks/215328/logs/events.3.1.log

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

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