[devel] I: imported libraries

[devel] I: imported libraries

[Igor Vlasenko]

Уважаемые коллеги,

Залил в Сизиф около 100 пакетов новых библиотек из Федоры, на которых
тестировал движок SourceAnalyzer (см. утилиту buildreq-src).

Движок показал себя очень хорошо, все проблемы, которые возникали при
сборке, были в основном из другой оперы, не связанной собственно с
роботом: отсутствие некоторых зависимостей в Сизифе,
неполнота базы DistroMap, которая не все зависимости умела транслировать,
и различные особенности апстрима, как то недолинковка 
verify-elf: ERROR: ./usr/lib64/lib...: undefined symbol: ...
error: call to __builtin___strcpy_chk will always overflow destination buffer
-rpath /usr/lib64 и т.д. и т.п.

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

Что касается сопровождения роботосборных пакетов, на багзилу я реагирую, 
и пока я справляюсь с сопровождением, но в перспективе хочу разделить -
для пакетов,  которым нужно тестирование пользователем --
пользовательских приложений -- думаю завести отдельного
псевдопользователя (converter?), 
и организовывать их тестирование силами ALTLinux Testers Team.

Поддержку же библиотек и прочего, которое перепоручать силам ALTLinux
Testers Team (предположительно, из ревностных, но еще не опытных
пользователей) рано, думаю оставить себе и всем желающим 
опытным пользователям -- пакеты на @everybody, с радостью раздаются
всем желающим в любой момент :) 

Иногда говорят "робопакеты fedoraimport фактически не поддерживаются"
Это не совсем так. В федоре есть человек, который этот пакет поддерживает -
его работу можно мержить вручную, можно автоматом.
а дублировать его работу смысла мало.
У нас есть и без этого много работы -  в сизифе багов нефикшеных море.

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

Между федорой и нами наблюдаемая разница сейчас составляет около 6000
пакетов. из них, наверное, 300-600 пакетов у нас на самом деле есть
под другими именами, но руками перебрать такое количество пока не
реально :( 

Если вдруг увидите такой пакет - пишите, мусор надо удалять.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] I: imported libraries

[thecrux]

On Mon, Dec 19, 2011 at 10:01:56PM +0200, Igor Vlasenko wrote:
> Уважаемые коллеги,
> 
> Залил в Сизиф около 100 пакетов новых библиотек из Федоры, на которых
> тестировал движок SourceAnalyzer (см. утилиту buildreq-src).

Простите за прямоту, но это начинает напоминать синдром Диогена.
Зачем нужны эти пакеты? Кому-нибудь когда-нибудь потребуется?

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

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

Если кому-то потребуется - сам и соберёт и будет поддерживать.

> Иногда говорят "робопакеты fedoraimport фактически не поддерживаются"
> Это не совсем так. В федоре есть человек, который этот пакет поддерживает -
> его работу можно мержить вручную, можно автоматом.
> а дублировать его работу смысла мало.

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

> У нас есть и без этого много работы -  в сизифе багов нефикшеных море.

Как фиксить баги, если майнтейнеру будет лень разобраться даже со сборкой
новой версии.

> Если вдруг увидите такой пакет - пишите, мусор надо удалять.

Здравая мысль

-- 
Vladimir Lettiev aka crux ✉ theCrux@gmail.com

Re: [devel] I: imported libraries

[Sergey Y. Afonin]

On Wednesday, December 21, 2011, thecrux@gmail.com wrote:

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

Мне тоже кажется, что не надо тащить библиотеки до момента, пока они,
конкретные, кому-то не станут нужны.

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

Re: [devel] I: imported libraries

[Денис Смирнов]

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

On Wed, Dec 21, 2011 at 12:05:10PM +0400, thecrux@gmail.com wrote:

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

Затем, что далеко не все пользователи Сизифа -- разработчики. И не все из
разработчиков -- становятся мантейнерами.

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

А этот юзверь может в будущем стать мантейнером.

Ну и, откровенно говоря, при нынешнем количестве и активности мантейнеров
-- качество скопированных пакетов не сильно уступает _среднему_ качеству
сборки пакетов. И оно еще будет улучшаться.

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

Они и сопровождаются специалистом. В федоре.

>> У нас есть и без этого много работы -  в сизифе багов нефикшеных море.
> Как фиксить баги, если майнтейнеру будет лень разобраться даже со сборкой
> новой версии.

Смотря каких пакетов.

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: imported libraries

[Paul Wolneykien]

21.12.2011 12:05, thecrux@gmail.com пишет:
> On Mon, Dec 19, 2011 at 10:01:56PM +0200, Igor Vlasenko wrote:
>> Уважаемые коллеги,
>>
>> Залил в Сизиф около 100 пакетов новых библиотек из Федоры, на которых
>> тестировал движок SourceAnalyzer (см. утилиту buildreq-src).
> 
> Простите за прямоту, но это начинает напоминать синдром Диогена.
> Зачем нужны эти пакеты? Кому-нибудь когда-нибудь потребуется?
> 
> К сожалению, ситация такова, что все пакеты собираются в одну кучу
> и нет никакой возможности выделить, что хорошо сопровождается, а что
> сопровождается кое-как или вообще не глядя кидается в общий котёл.
> Такие вбросы демотивируют разработчиков, какой смысл пытаться разбираться
> с программами: как они функционируют, как собираются, какие происходят
> изменения и какие есть проблемы,    если рядом человек не глядя вёдрами
> заливает копии пакетов из других дистрибутивов и все молчат и делают вид,
> что это вобщем-то неплохо и даже правильно.

  То, как они, программы, собираются и какие происходят изменения очень
хорошо можно узнать именно глядя на робота. Потому что на робота можно
посмотреть не только снаружи (на процесс и результат сборки), но и изнутри.

> 
>> Это открывает доргу к тому, чтобы в перспективе начать тотальный
>> импорт отсутствующих у нас библиотек из Федоры, чтобы если понадобится
>> собрать в Сизиф какое-то приложение, все нужные библиотеки уже были
>> под рукой.
> 
> Если кому-то потребуется - сам и соберёт и будет поддерживать.
> 
>> Иногда говорят "робопакеты fedoraimport фактически не поддерживаются"
>> Это не совсем так. В федоре есть человек, который этот пакет поддерживает -
>> его работу можно мержить вручную, можно автоматом.
>> а дублировать его работу смысла мало.
> 
> Любой здравомыслящий человек при прочих равных обстоятельствах выберет
> дистрибутив, где нужная ему программа сопровождается компетентным
> специалистом, а не тупым роботом.

  А если программа сопровождается компетентным специалистом с помощью
[не такого уж и тупого] робота?

> 
>> У нас есть и без этого много работы -  в сизифе багов нефикшеных море.
> 
> Как фиксить баги, если майнтейнеру будет лень разобраться даже со сборкой
> новой версии.
> 
>> Если вдруг увидите такой пакет - пишите, мусор надо удалять.
> 
> Здравая мысль
> 

Re: [devel] I: imported libraries

[Paul Wolneykien]

21.12.2011 13:28, Sergey Y. Afonin пишет:
> On Wednesday, December 21, 2011, thecrux@gmail.com wrote:
> 
>>> Это открывает доргу к тому, чтобы в перспективе начать тотальный
>>> импорт отсутствующих у нас библиотек из Федоры, чтобы если понадобится
>>> собрать в Сизиф какое-то приложение, все нужные библиотеки уже были
>>> под рукой.
>>
>> Если кому-то потребуется - сам и соберёт и будет поддерживать.
> 
> Мне тоже кажется, что не надо тащить библиотеки до момента, пока они,
> конкретные, кому-то не станут нужны.
> 

  Снова предлагаю рассмотреть концепцию импорта-по-требованию.

Re: [devel] I: imported libraries

[Michael Shigorin]

On Wed, Dec 21, 2011 at 02:16:22PM +0400, Денис Смирнов wrote:
> > Любой здравомыслящий человек при прочих равных
> > обстоятельствах выберет дистрибутив, где нужная ему программа
> > сопровождается компетентным специалистом, а не тупым роботом.
> Они и сопровождаются специалистом. В федоре.

Тут ещё один момент: а в чём разница?  Что именно майнтейнер
привносит в пакет -- сборку с проверкой, метаинформацию,
интеграцию с другими запчастями дистрибутива?..

Механически пакетить -- тоже путь в никуда.  См., e.g.,
`curl -Ls http://tinyurl.com/6p3al52 | grep -A4 git | fmt`

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] I: imported libraries

[thecrux]

On Wed, Dec 21, 2011 at 03:03:49PM +0400, Paul Wolneykien wrote:
 
>   То, как они, программы, собираются и какие происходят изменения очень
> хорошо можно узнать именно глядя на робота. Потому что на робота можно
> посмотреть не только снаружи (на процесс и результат сборки), но и изнутри.
...
>   А если программа сопровождается компетентным специалистом с помощью
> [не такого уж и тупого] робота?

Я же не говорю, что автоматизация и роботы это плохо. Нет, это круто!

Смысл претензий в том, что в Sisyphus вбросили никому (даже самому
сборщику) не нужный софт. Робот позволил увеличить площадь поражения.
Не исключено, что софт может банально не работать. Ну проходит какие-то
формальные критерии (собираемость, устанавливаемость) и достаточно.
Это плохой, негодный пример сопровождения пакетов.

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

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

-- 
Vladimir Lettiev aka crux ✉ theCrux@gmail.com

Re: [devel] I: imported libraries

[Paul Wolneykien]

21.12.2011 16:25, thecrux@gmail.com пишет:
> Я же не говорю, что автоматизация и роботы это плохо. Нет, это круто!
> 
> Смысл претензий в том, что в Sisyphus вбросили никому (даже самому
> сборщику) не нужный софт. Робот позволил увеличить площадь поражения.
> Не исключено, что софт может банально не работать. Ну проходит какие-то
> формальные критерии (собираемость, устанавливаемость) и достаточно.
> Это плохой, негодный пример сопровождения пакетов.

  А если на примере подсистем рассмотреть? Вот мне, к примеру, нужен
пакет octave-image, входящий в состав Octave-Forge. Раньше я собирал его
отдельно, и для этого пришлось собрать ещё кое что из Octave-Forge, но
далеко не всё. Получается, что часть подсистемы я уже втащил в Сизиф,
написав типовой спек и файлтриггер. Мне показалось логичным попробовать
использовать эти наработки для импорта остальных пакетов Octave-Forge
хотя бы потому, что если в будущем кому-нибудь понадобиться другой пакет
из Octave-Forge, то этот другой пользователь может решить изобрести свой
велосипед. Я не то, чтобы против велосипедизма в принципе, я против
тупой работы и за распространение хороших решений.

  И тогда я обратился к Игорю с просьбой помочь мне написать робот для
импорта, по возможности, всего Octave-Forge. К моему большому удивлению,
Игорь помог мне не столько словом, сколько делом, целиком написав этого
робота. Я подправил скрипты лишь совсем немного. И теперь у нас в Сизифе
существенно больше пакетов Octave-Forge.

  Хорошо это или плохо, учитывая, что я проверяю работоспособность
одного лишь octave-image? Мне кажется, что это хорошо, это лучше, чем
один octave-image. Потому что если выясниться, что какие-то пакеты не
работают, то на них можно вешать баги, исправления которых будут
положительно сказываться на качестве импорта всей подсистемы в целом.


  А вот что можно сказать по поводу массового импорта ничем не связанных
между собой внешних объектов, я пока не знаю.  Мне всё-таки кажется, что
хорошо бы их иметь в потенциале. Т.е. пусть робот делает тестовые
сборки, но не коммитит их в Сизиф, а просто ставит «галочку», что вот
этот вот пакет можно, в случае чего, импортировать за пару минут, по
требованию пользователя, а вот с импортом этого пакета имеются проблемы
(которые интересны, в основном, автору робота).

  Думаю всех бы устроило, если бы роботы создавали «потенциальное облако
пакетов». Автор роботов получал бы ценную информацию для дальнейшего
совершенствования технологии. А пользователи получили бы возможность
«использовать полуфабрикаты»: понадобился пакет — обратился к владельцу
облака с просьбой скопировать пакет в Сизиф («разморозить») и пользуйся
на здоровье, тестируй и даже сопровождай. А если пакет больше не нужен,
то такие orphaned пакеты можно обратно из Сизифа в облако вернуть, до
следующего раза.


    Паша.

Re: [devel] I: imported libraries

[Igor Vlasenko]

On Wed, Dec 21, 2011 at 12:05:10PM +0400, thecrux@gmail.com wrote:
> Простите за прямоту, но это начинает напоминать синдром Диогена.
> Зачем нужны эти пакеты? Кому-нибудь когда-нибудь потребуется?

Действительно, как то сложилось, что много мифов и слухов
вокруг пакетов, собираемых роботом. Незнание темы порождает
FUD, как например, следующее высказывание:
> Смысл претензий в том, что в Sisyphus вбросили никому (даже самому
> сборщику) не нужный софт. Робот позволил увеличить площадь поражения.
> Не исключено, что софт может банально не работать.

Давайте разберемся с цифрами в руках,
что я сейчас сопровождаю с помощью робота импорта из Федоры.

   39 import/fc/aspell.list
  112 import/fc/hunspell.list
   40 import/fc/hyphen.list
   17 import/fc/mythes.list
    5 import/fc/stardict.list

Это все i18n. Любой порядочный дистрибутив должен иметь i18n.

    2 import/fc/firmware.list
почему бы и нет

  193 import/fc/fonts.list
напомню, я провел большую работу по шрифтам, полиси, триггер,
заодно обучил импорту робота. Шрифты нужны не всем, но тем, 
кому нужны - мало не бывает.

  144 import/fc/games.list
    8 import/fc/java.list
игрушки.
ALTLinux testers team провела большую работу по тестированию 
этих пакетов, и, кстати, почти все выявленные баги связаны с нашими
библиотеками в Сизифе, которые, кстати, сопровождаются руками.

   68 import/fc/javalib.list
no comment
  105 import/fc/libs.list
тестовое множество. Стоило ли так из-за него 
так переживать? Обременят ли эти пакеты Сизиф?

   12 import/fc/libs-renamed.list
   81 import/fc/misc.list
Игрушки тянули за собой некоторые библиотеки,
плюс некотрые приложения выглядели интересными.
и тоже тянули за собой библиотеки.
   26 import/fc/mingw32.list
у нас эта подсистема заброшена, стоило бы ее перевести на робота
    2 import/fc/python.list
мне нужно собрать из федоры cnucnu.
пока собираю пререквизиты.
    2 import/fc/russianfedora.list
собрал из russianfedora bino - плеер 3D фильмов.
отдам любому желающему.
  856 итого

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

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] I: imported libraries

[Igor Vlasenko]

On Wed, Dec 21, 2011 at 04:59:31PM +0400, Paul Wolneykien wrote:
>   Думаю всех бы устроило, если бы роботы создавали ??потенциальное облако
> пакетов??. 

Тоже возможен такой вариант,
завести RPMS.cpan, и т.д.

Но пока у нас даже RPMS.debug не получается выпилить.
Возможно, стоило бы разделить как сущности Сизиф внутренний,
который в сборочнице, и Сизиф внешний, который раз в сутки
публикуется на ftp, и распиливать на RPMS.debug и т.д.
уже внешний Сизиф.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] I: imported libraries

[Paul Wolneykien]

21.12.2011 22:37, Igor Vlasenko пишет:
> On Wed, Dec 21, 2011 at 04:59:31PM +0400, Paul Wolneykien wrote:
>>   Думаю всех бы устроило, если бы роботы создавали ??потенциальное облако
>> пакетов??. 
> 
> Тоже возможен такой вариант,
> завести RPMS.cpan, и т.д.
> 
> Но пока у нас даже RPMS.debug не получается выпилить.
> Возможно, стоило бы разделить как сущности Сизиф внутренний,
> который в сборочнице, и Сизиф внешний, который раз в сутки
> публикуется на ftp, и распиливать на RPMS.debug и т.д.
> уже внешний Сизиф.
> 

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

Re: [devel] I: imported libraries

[Dmitriy Kruglikov]

22 декабря 2011 г. 12:09 пользователь Paul Wolneykien  написал:
> Т.е. смысл в том, чтобы роботы собирали пакеты на базе Сизифа, и эти пакеты
> спокойно можно было потом поставить в Сизиф, но в pkglist Сизифа они бы
> не публиковались. И никаких замкнутых компонентов, кроме classic. Это
> возможно?
Да, это возможно, если сделать еще один репозиторй, дополняющий Сизиф.
И в него уже собирать пакеты.


-- 
Best regards,
 Dmitriy Kruglikov.
    QString at, dot, mail, XMPP;
    at = "@";
    dot = ".";
    mail = "Dmitriy.Kruglikov" + $at +"gmail" + $dot + "com";
    XMPP = $mail;

Re: [devel] I: imported libraries

[Igor Vlasenko]

On Thu, Dec 22, 2011 at 02:09:20PM +0400, Paul Wolneykien wrote:
>   По поводу компонентов у нас уже много говорили. Мне представляется,
> что на полигоне у роботов должен быть тот же RPMS.classic, что и в
> Сизифе, но с дополнительными пакетами, которые эти роботы собирают. Т.е.
> смысл в том, чтобы роботы собирали пакеты на базе Сизифа, и эти пакеты
> спокойно можно было потом поставить в Сизиф, но в pkglist Сизифа они бы
> не публиковались. И никаких замкнутых компонентов, кроме classic. Это
> возможно?

Имеются в виду карманы? да, хрошая была бы вещь.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] I: imported libraries

[Paul Wolneykien]

23.12.2011 00:56, Igor Vlasenko пишет:
> On Thu, Dec 22, 2011 at 02:09:20PM +0400, Paul Wolneykien wrote:
>>   По поводу компонентов у нас уже много говорили. Мне представляется,
>> что на полигоне у роботов должен быть тот же RPMS.classic, что и в
>> Сизифе, но с дополнительными пакетами, которые эти роботы собирают. Т.е.
>> смысл в том, чтобы роботы собирали пакеты на базе Сизифа, и эти пакеты
>> спокойно можно было потом поставить в Сизиф, но в pkglist Сизифа они бы
>> не публиковались. И никаких замкнутых компонентов, кроме classic. Это
>> возможно?
> 
> Имеются в виду карманы? да, хрошая была бы вещь.

  Не знаю, карманы это или нет. Вот Дима удачно выразился «дополняющий
репозиторий».

Re: [devel] I: imported libraries

[thecrux]

On Fri, Dec 23, 2011 at 01:15:40AM +0400, Paul Wolneykien wrote:
> 23.12.2011 00:56, Igor Vlasenko пишет:
> > On Thu, Dec 22, 2011 at 02:09:20PM +0400, Paul Wolneykien wrote:
> >>   По поводу компонентов у нас уже много говорили. Мне представляется,
> >> что на полигоне у роботов должен быть тот же RPMS.classic, что и в
> >> Сизифе, но с дополнительными пакетами, которые эти роботы собирают. Т.е.
> >> смысл в том, чтобы роботы собирали пакеты на базе Сизифа, и эти пакеты
> >> спокойно можно было потом поставить в Сизиф, но в pkglist Сизифа они бы
> >> не публиковались. И никаких замкнутых компонентов, кроме classic. Это
> >> возможно?
> > 
> > Имеются в виду карманы? да, хрошая была бы вещь.
> 
>   Не знаю, карманы это или нет. Вот Дима удачно выразился «дополняющий
> репозиторий».

Идея мне кажется очень хорошей, разбить classic на base и кучку разных
дополняющих репозиториев ака оверлеев, каждый имеющий своё предназначение.
Такая идея постоянно высказывается участниками команды и постоянно
игнорируется теми, кто рулит инфраструктурой.

Может ли мне кто-нибудь напомнить когда проходило обсуждение о склеивании
base contrib и прочих компонент в единый classic и чем это было вызвано?

На сегодняшний день у нас ~15Мб индексы, которые приходится каждый раз
скачивать даже если обновился один пакет на 10Кб, которого вы в жизни
не поставите на свою систему. Медленный apt (это особенно заметно на слабых
машинах), который, судя по профайлингу, прожирает всё процессорное время
за сортировкой данных из этих индексов.

Плюсов у системы с множеством оверлеев много. Это и более лёгкие индексы и
логическое разделение компонентов (например, server, kde, gnome, games, cpan,
pypi, jpackage и др.).
Для разных оверлеев могут быть разные требования к безопасности (выпуск
security updates), работоспособности (например, экспериментальные) и т.п.
Оверлеи могли бы иметь своих администраторов, которые бы управляли
включением/удалением пакетов.

-- 
Vladimir Lettiev aka crux ✉ theCrux@gmail.com

Re: [devel] I: overlays

[Paul Wolneykien]

23.12.2011 10:44, thecrux@gmail.com пишет:
> On Fri, Dec 23, 2011 at 01:15:40AM +0400, Paul Wolneykien wrote:
>> 23.12.2011 00:56, Igor Vlasenko пишет:
>>> On Thu, Dec 22, 2011 at 02:09:20PM +0400, Paul Wolneykien wrote:
>>>>   По поводу компонентов у нас уже много говорили. Мне представляется,
>>>> что на полигоне у роботов должен быть тот же RPMS.classic, что и в
>>>> Сизифе, но с дополнительными пакетами, которые эти роботы собирают. Т.е.
>>>> смысл в том, чтобы роботы собирали пакеты на базе Сизифа, и эти пакеты
>>>> спокойно можно было потом поставить в Сизиф, но в pkglist Сизифа они бы
>>>> не публиковались. И никаких замкнутых компонентов, кроме classic. Это
>>>> возможно?
>>>
>>> Имеются в виду карманы? да, хрошая была бы вещь.
>>
>>   Не знаю, карманы это или нет. Вот Дима удачно выразился «дополняющий
>> репозиторий».
> 
> Идея мне кажется очень хорошей, разбить classic на base и кучку разных
> дополняющих репозиториев ака оверлеев, каждый имеющий своё предназначение.
> Такая идея постоянно высказывается участниками команды и постоянно
> игнорируется теми, кто рулит инфраструктурой.
> 
> Может ли мне кто-нибудь напомнить когда проходило обсуждение о склеивании
> base contrib и прочих компонент в единый classic и чем это было вызвано?
> 
> На сегодняшний день у нас ~15Мб индексы, которые приходится каждый раз
> скачивать даже если обновился один пакет на 10Кб, которого вы в жизни
> не поставите на свою систему. Медленный apt (это особенно заметно на слабых
> машинах), который, судя по профайлингу, прожирает всё процессорное время
> за сортировкой данных из этих индексов.
> 
> Плюсов у системы с множеством оверлеев много. Это и более лёгкие индексы и
> логическое разделение компонентов (например, server, kde, gnome, games, cpan,
> pypi, jpackage и др.).
> Для разных оверлеев могут быть разные требования к безопасности (выпуск
> security updates), работоспособности (например, экспериментальные) и т.п.
> Оверлеи могли бы иметь своих администраторов, которые бы управляли
> включением/удалением пакетов.

  Мне кажется, что слово «оверлей» означает, что эти объекты должны
пересекаться, т.е. частично иметь одинаковый набор пакетов — совсем как
разные чруты в хешере разделяют один базовый набор пакетов.

  Но можно ещё раз кратко: чем «оверлей» отличается от «компоненты»?
Основная претензия к компонентам, насколько мне помниться, сводилась к
тому, что их трудно/невозможно сделать замкнутыми. В случае оверлеев это
не так?

  И ещё. Как технически ты видишь процедуру разделения Сизифа на оверлеи?

Re: [devel] I: overlays

[thecrux]

On Fri, Dec 23, 2011 at 02:18:44PM +0400, Paul Wolneykien wrote:
> 
>   Мне кажется, что слово «оверлей» означает, что эти объекты должны
> пересекаться, т.е. частично иметь одинаковый набор пакетов — совсем как
> разные чруты в хешере разделяют один базовый набор пакетов.
>   Но можно ещё раз кратко: чем «оверлей» отличается от «компоненты»?

Наверно я путаю терминологию. Но AFAIK есть два варианта разделения монолитного
репозитория:

 * компоненты в виде такой записи в source.list:
   rpm path/to/rpms arch comp1 comp2 comp3

 * дополнительные репозитории:
   rpm path/to/repo arch comp
   rpm path/to/another/repo arch comp

Существует ли между ними большая разница (в плане работы apt) - не знаю.
Но в плане организации репозиториев разница большая.

Компоненты позволяют разбить большой репозиторий на части и пользователь
подключает только нужные ему части. Пакетная база в компонентах не
пересекается.

Дополнительные репозитории подключаются в дополнении к основному, они
несамостоятельны и требуют подключённого какого-то базового репозитория.
Кроме того они могут содержать пакеты уже имеющиеся в базовом репозитории,
но имеющие другую эпоху:версию - именно поэтому я говорю о таком
репозитории как о наложении ( overlay - перекрывать )
И в отличие от компонентного разбития, дополнительный репозиторий может
находится на другом ресурсе и быть подписан другой подписью.

> Основная претензия к компонентам, насколько мне помниться, сводилась к
> тому, что их трудно/невозможно сделать замкнутыми. В случае оверлеев это
> не так?

Кто, где и когда это говорил? Я пока не смог найти обсуждение.

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

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

>   И ещё. Как технически ты видишь процедуру разделения Сизифа на оверлеи?

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

-- 
Vladimir Lettiev aka crux ✉ theCrux@gmail.com

Re: [devel] I: overlays

[Denis G. Samsonenko]

День добрый!

23 декабря 2011 г. 19:48  thecrux написал:
> Кроме того они могут содержать пакеты уже имеющиеся в базовом репозитории,
> но имеющие другую эпоху:версию - именно поэтому я говорю о таком
> репозитории как о наложении ( overlay - перекрывать )

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

-- 
Всего доброго,

Денис.

Re: [devel] I: overlays

[thecrux]

On Fri, Dec 23, 2011 at 09:31:16PM +0600, Denis G. Samsonenko wrote:
> День добрый!
> 
> 23 декабря 2011 г. 19:48  thecrux написал:
> > Кроме того они могут содержать пакеты уже имеющиеся в базовом репозитории,
> > но имеющие другую эпоху:версию - именно поэтому я говорю о таком
> > репозитории как о наложении ( overlay - перекрывать )
> 
> В таком случае могут возникнуть конфликты при попытке использования
> разных компонент одновременно? когда они содержат разные версии одного
> и того же пакета. Лучше, если бы пакеты, находящиеся в базовом репо
> никогда бы не дублировались в дополнительных, иначе они уже тогда не
> являются базовыми.

В этом ведь может быть весь смысл оверлея - например, оверлей с альфа
версией firefox или chromium для тестирования заинтересованными.
Конфликтов не будет, apt выберет более новую версию.

-- 
Vladimir Lettiev aka crux ✉ theCrux@gmail.com

[devel] I: overlays

[Denis G. Samsonenko]

Привет!

23 декабря 2011 г. 22:50 thecrux написал:
> В этом ведь может быть весь смысл оверлея - например, оверлей с альфа
> версией firefox или chromium для тестирования заинтересованными.
> Конфликтов не будет, apt выберет более новую версию.

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

Вообще, тут тогда возникает 2 типа таких оверлеев. Одни постоянные,
которые содержат определённые компоненты системы, которые не зависят
друг от друга (и не пересекаются), а только от базовой части. Другой
тип -- это маленькие временные репо для тестов некоторых компонент.
Потестили, убедились, что всё хорошо -- влили в базовую систему или в
какой-то из больших дополнительных.

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

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

--
Всего доброго,

Денис.

[devel] [JT] I: overlay bantustans

[Igor Vlasenko]

On Fri, Dec 23, 2011 at 02:18:44PM +0400, Paul Wolneykien wrote:
> >>> Имеются в виду карманы? да, хрошая была бы вещь.
> >>   Не знаю, карманы это или нет. Вот Дима удачно выразился ??дополняющий
> >> репозиторий??.

Мне в этих оверлеях не нравится то, что разговоры о них
пошли в аккурат в тему с роботами :( 
Т.е. как было в ЮАР: раз уж без ниггеров^Wроботов обойтись нельзя,
давайте загоним их в бантустаны^Wоверлеи.

Т.е. противопоставление вручную упакованных пакетов как 
"хороших" и упакованых с помощью средств автоматизации как "плохих".

К сожалению, то, что пакет упакован вручную, не значит, что пакет
сопровождается. Многие пакеты по факту не сопровождаются.
Хороший майнтайнер хотя бы говорит - руки не доходят, сделайте,
пожалуйста, сами, а плохой просто не реагирует :(

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

Пакеты, собираемые средствами автоматизации ("роботами"), тоже делятся 
на сопровождаемые и не сопровождаемые. Например, оверлей для p6/t6
RPMS.autoports -- это несопровождаемые пакеты. НО: об этом 
четко написано на wiki в документации по autoports.

Также, я, возможно, сделаю когда-нибудь и другие оверлейные репозитории,
RPMS.cpan, RPMS.autoimports, и т.д.
Но там везде будет написано: не сопровождаются, на свой страх и риск,
иначе ССЗБ.

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

А бояться непонятно чего не стоит.

P.S. Конечно, при росте числа пакетов рано или поздно меня не хватит,
но я уже заранее думаю как жить и в том случае, организовываю 
сотрудничество с нашей Testers Team.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] [JT] I: overlay bantustans

[Paul Wolneykien]

23.12.2011 23:16, Igor Vlasenko пишет:
> Мне в этих оверлеях не нравится то, что разговоры о них
> пошли в аккурат в тему с роботами :( 
> Т.е. как было в ЮАР: раз уж без ниггеров^Wроботов обойтись нельзя,
> давайте загоним их в бантустаны^Wоверлеи.

  Напоминаю уважаемым слушателям, что лично я, поднял вопрос о
компонентах/оверлеях в контексте «копирования пакетов по требованию»
(copy-on-demand). Напомню также, что вопрос этот возник не столько по
причине скептического отношения к качеству автоматической сборки,
сколько по причине потенциально опасного её количества. Поэтому оверлей
предлагаю рассматривать не как «бантустан», а как место где пакеты
ожидают своей инкарнации в Сизифе.

Re: [devel] I: overlays

[Michael Shigorin]

On Fri, Dec 23, 2011 at 04:48:42PM +0400, thecrux@gmail.com wrote:
> >   И ещё. Как технически ты видишь процедуру разделения Сизифа на оверлеи?
[...]
> Или идти от обратного, вытаскивать пакеты по одному в отдельные компоненты.

Я как-то упоминал, что готов выдать список своих пакетов,
для которых считаю уместным статус contrib.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] [JT] I: overlay bantustans

[Michael Shigorin]

On Fri, Dec 23, 2011 at 09:16:34PM +0200, Igor Vlasenko wrote:
> > >>> Имеются в виду карманы? да, хрошая была бы вещь.
> > >>   Не знаю, карманы это или нет. Вот Дима удачно выразился
> > >>   ??дополняющий репозиторий??.
> Мне в этих оверлеях не нравится то, что разговоры о них пошли в
> аккурат в тему с роботами :( Т.е. как было в ЮАР: раз уж без
> ниггеров^Wроботов обойтись нельзя, давайте загоним их в
> бантустаны^Wоверлеи.

Игорь, мне кажется, что тут чуть другое: робот по определению
является майнтейнером "N+1-го класса", и не все согласны видеть
результаты своих тщательно выверенных трудов среди тысяч пакетов
по конверсии.  Это и перекликается с той темой, что не все пакеты
одного и того же _человека_ будут одинаково качественны во многих
случаях (как минимум в моём, да и ldv@ вряд ли сейчас использует
nethack в повседневной разработке).

> К сожалению, то, что пакет упакован вручную, не значит, что пакет
> сопровождается. Многие пакеты по факту не сопровождаются.

Это да.

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

И за это спасибо.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] [JT] I: overlay bantustans

[Igor Vlasenko]

On Mon, Dec 26, 2011 at 01:51:39PM +0200, Michael Shigorin wrote:
> Игорь, мне кажется, что тут чуть другое: робот по определению
> является майнтейнером "N+1-го класса" 

Это в значительной степени миф.

И сам же виноват, так как не занимался популяризацией топика :(

робот вырождается в майнтейнера "N+1-го класса" без присмотра 
со стороны человека. Так, наверное, оправданно говорить, если
речь идет об автономных, сами по себе собирающих робото-песочницах 
наподобие autoports.

Под присмотром человека это такой же инструмент, как и,
например, add_changelog.

Тот же cronbuild - пример решения "1-го класса" для пакетов,
у которых критерием качества является оперативность.
И в других применениях, поддержка (с постоянным усовершенствование) 
для своих задач _специализированного_ робота (наподобие сборщика 
пакетов octave) приводит не только к экономии времени и сил,
но и к повышению качества сопровождения.

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

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] I: imported libraries

[Vitaly Lipatov]

 On Thu, 22 Dec 2011 22:56:12 +0200, Igor Vlasenko wrote:
 ...
> Имеются в виду карманы? да, хрошая была бы вещь.
 Одно не понимаю. Почему карманы давно разработаны sin@,
 и в Etersoft используются уже года полтора, а в devel@ всё
 вздыхают о том, что хорошо бы они были...

-- 
 С уважением,
 Виталий Липатов,
 Etersoft

[devel] Q: personal package repositories: user PoV

[Dmitry V. Levin]

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

On Wed, Dec 28, 2011 at 03:50:58AM +0400, Vitaly Lipatov wrote:
> Одно не понимаю. Почему карманы давно разработаны sin@,
> и в Etersoft используются уже года полтора, а в devel@ всё
> вздыхают о том, что хорошо бы они были...

[карманы - это персональные репозитории пакетов, представляющие собой
дополнения к некоторому базовому репозиторию типа Sisyphus]

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

Допустим, что у персональных репозиториев есть пользователи, которые
устанавливают пакеты из этих репозиториев.  Это не очень сильное
допущение, поскольку если из репозиториев вообще не устанавливают пакеты,
то они не сильно отличаются от test-only заданий (из которых, кстати
говоря, можно устанавливать пакеты), и в данном случае не интересны.

Устанавливать пакеты из такого репозитория можно либо с автоматическим
разрешением зависимостей (с помощью apt-get, подключив этот репозиторий в
качестве источника для обновления), либо вручную (скачивая и устанавливая
пакеты с помощью rpm).

Что происходит, когда некоторое непустое подмножество пакетов персонального
репозитория пересобирается (из того же исходного кода, из которого они были
собраны ранее) либо по явной команде мейнтейнера, либо в результате
автоматической процедуры, которая выявляет изменения сборочной среды
пакетов?  Как и в случае повторной сборки test-only задания, в результате
пересборки персонального репозитория свежепересобранные пакеты оказываются на
месте собранных ранее, причем имена файлов пакетов и их ключевые
характеристики (NSVR: %name, %serial, %version, %release) с высокой
вероятностью остаются прежними.

В какой ситуации оказывается пользователь, который установил пакеты из
этого персонального репозитория до пересборки?  Поскольку NSVR
пересобранных пакетов не изменились, обновить установленные пакеты будет
непросто - "apt-get dist-upgrade" не поможет, остаются ручные режимы:
либо "apt-get reinstall" с явным указанием списка пакетов, либо rpm
(скачивание всех пакетов персонального репозитория с последующим "rpm -F")

Ситуация, в которой оказывается пользователь пересобранного персонального
репозитория, становится совсем сложной, когда у пересобранных пакетов
существенным образом меняются зависимости (например, в результате
пересборки из-за soname change в базовом репозитории, или чего-нибудь
подобного).  В этом случае dist-upgrade вынужден предложить пользователю
удалять пакеты, "rpm -F" может не справиться из-за неудовлетворенных
зависимостей, и обновить ранее установленные пакеты (особенно если их было
достаточно много) из персонального репозитория становится совсем непростой
задачей, сваливать которую на пользователя просто неправильно.

Какие могут быть варианты решения этой проблемы обновления из
персонального репозитория?

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

2. Автоматическое изменение NSVR пересобираемых пакетов самой сборочной
системой по некоторым правилам.  На практике это, скорее всего, означает
изменение %release пакетов.  Поскольку в большинстве пакетов %release
указан в спек-файлах явно, это, очевидно, означает редактирование
спек-файлов сборочной системой, что сопряжено с известными техническими
трудностями (у нас разработаны специальные инструментальные средства для
автоматического увеличения релиза, которые охватывают большинство
существующих пакетов, но в общем случае эта задача, как известно, не имеет
решения), и в качестве побочного эффекта приводит к изменению исходных
пакетов.  Мне этот вариант, опирающийся на решение задачи, не имеющей
решение, не нравится.
Альтернативно, можно предложить всем мейнтейнерам формировать %release
с помощью макроса, который сборочная система могла бы использовать для
автоматического увеличения %release.  Оставляя за скобками вопрос о том,
что это мог бы быть за макрос, мне кажется сомнительным, чтобы ленивые
по своей сути мейнтейнеры справились бы с таким радикальным изменением
правил составления спек-файлов.

3. Добавление к NSVR пакета еще одной характеристики B.  Автоматическое
увеличение этой характеристики самой сборочной системой при каждой
пересборке пакета.  Сквозная адаптация всех инструментальных средств на
стороне пользователя (в первую очередь apt и rpm) для учета этой
характеристики B при обработке пакетов.  Тут возможны различные варианты.
Можно включать эту характеристику в имя файла собранного пакета, а можно
этого не делать.  Можно включать эту характеристику в пользовательские
интерфейсы выбора пакета (например, чтобы можно было указать ее для
уточнения пакета при вызове apt-get и rpm), а можно этого не делать.
Наконец, можно придумать для этой характеристики B какой-то новый тэг rpm,
а можно попробовать адаптировать какой-нибудь из уже существующих.
Чем больше будет таких мест, где сможет/будет фигурировать B, тем больше
рычагов управления будет у пользователя, с одной стороны, и тем сложнее
будет реализация и хуже обратная совместимость, с другой стороны.

4. На самом деле в rpm уже есть один тэг, который годится на роль такой
характеристики B.  Более того, значение этого тэга уже сейчас
автоматически увеличивается самой сборочной системой при каждой пересборке
пакета.  Более того, этот тэг уже сейчас rpm учитывает при обновлении
пакетов именно таким образом, как это нужно для решения нашей задачи: при
равенстве NSVR у ранее установленного и предлагаемого для обновления пакета
rpm соглашается на обновление, если у обновляемого пакета значение этого
тэга больше.  Этот тэг называется BUILDTIME, и его можно получить с
помощью rpmquery:
$ rpmquery --qf '%{BUILDTIME}\n' -p Sisyphus/files/x86_64/RPMS/rpm-4.0.4-alt100.45.x86_64.rpm 
1327518688
Поддержку учета BUILDTIME при обновлении пакетов я добавил в rpm
много лет назад, так что можно полагать, что у всех наших пользователей
она уже есть.
Впрочем, apt-get на данный момент не поддерживает BUILDTIME, нет способа
указать BUILDTIME при вызове rpm, и BUILDTIME не включается в имя файла
пакета.  Тем не менее, на мой взгляд, внедрение BUILDTIME в качестве еще
одной характеристики для автоматического обновления пересобранных пакетов
из персональных репозиториев выглядит наиболее перспективным вариантом.

Меня, впрочем, несколько настораживает перспектива выпуска этого джинна
из бутылки.  Как только персональные репозитории можно будет пересобирать
без изменения исходного кода и это перестанет доставлять неудобства
пользователя, так сразу возникнет желание распространить эту практику на
базовые репозитории типа Sisyphus, чтобы автоматически пересобирать пакеты
без изменения исходного кода, NSVR и записи в %changelog в тех случаях,
когда пересборка необходима (soname change и т.п.).  В этом случае
включение BUILDTIME в имена файлов собираемых пакетов кажется мне
необходимым, но что делать с отсутствием записи в %changelog, непонятно.

Вот такие соображения.  Теперь можно комментировать. :)


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Q: personal package repositories: user PoV

[Led]

On Saturday 28 January 2012 02:19:39 Dmitry V. Levin wrote:
> Вот такие соображения.  Теперь можно комментировать. :)

Есть ещё одна характеристика, которую можно учитывать - Vendor

-- 
Led

Re: [devel] Q: personal package repositories: user PoV

[Денис Смирнов]

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

On Mon, Jan 30, 2012 at 02:14:15PM +0400, Исопенко Павел Радуевич wrote:

> Предлагаю немного изменить термин: вместо "персональный" (personal), в
> контексте package repositories,
> использовать определение "частный" (private). Поскольку, в общем случае,
> поддержкой кармана может заниматься более одной персоны. А в
> русскоязычном толковании, вдобавок, даёт ассоциацию на "частичный", то
> есть неполный, но с намёком на существование целого. Да и "приватный"
> звучит не хуже, не меняя сущности.

У этого слова уже есть другое значение, которое применяется в рамках
git.alt. К private git репозиториям ограниченный доступ, и это слово
принято использовать как антоним слову 'public'.

> Верно, вариант с BUILDTIME выглядит наиболее предпочтительным.

+1

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Q: personal package repositories: user PoV

[Alexey Tourbin]

On Sat, Jan 28, 2012 at 04:19:39AM +0400, Dmitry V. Levin wrote:
> 3. Добавление к NSVR пакета еще одной характеристики B.  Автоматическое
> увеличение этой характеристики самой сборочной системой при каждой
> пересборке пакета.  Сквозная адаптация всех инструментальных средств на
> стороне пользователя (в первую очередь apt и rpm) для учета этой
> характеристики B при обработке пакетов.  Тут возможны различные варианты.
> Можно включать эту характеристику в имя файла собранного пакета, а можно
> этого не делать.  Можно включать эту характеристику в пользовательские
> интерфейсы выбора пакета (например, чтобы можно было указать ее для
> уточнения пакета при вызове apt-get и rpm), а можно этого не делать.
> Наконец, можно придумать для этой характеристики B какой-то новый тэг rpm,
> а можно попробовать адаптировать какой-нибудь из уже существующих.
> Чем больше будет таких мест, где сможет/будет фигурировать B, тем больше
> рычагов управления будет у пользователя, с одной стороны, и тем сложнее
> будет реализация и хуже обратная совместимость, с другой стороны.
> 
> 4. На самом деле в rpm уже есть один тэг, который годится на роль такой
> характеристики B.  Более того, значение этого тэга уже сейчас
> автоматически увеличивается самой сборочной системой при каждой пересборке
> пакета.  Более того, этот тэг уже сейчас rpm учитывает при обновлении
> пакетов именно таким образом, как это нужно для решения нашей задачи: при
> равенстве NSVR у ранее установленного и предлагаемого для обновления пакета
> rpm соглашается на обновление, если у обновляемого пакета значение этого
> тэга больше.  Этот тэг называется BUILDTIME, и его можно получить с
> помощью rpmquery:
> $ rpmquery --qf '%{BUILDTIME}\n' -p Sisyphus/files/x86_64/RPMS/rpm-4.0.4-alt100.45.x86_64.rpm 
> 1327518688
> Поддержку учета BUILDTIME при обновлении пакетов я добавил в rpm
> много лет назад, так что можно полагать, что у всех наших пользователей
> она уже есть.

Результат сборки пакетов не должен зависеть от модельного времени t,
а должен зависеть только от ингредиентов, которые напрямую влияют на
результат сборки.  Таких ингредиентов два: B(S,C)->P, где S - исходный
код пакета, C - содержимое сборочного чрута.

Представление о времени в зависимостях вообще нерелевантно, и должно быть
исключено.  Например, если где-то требуется библиотечная функция foo(),
то должен быть способ представить зависимость на функцию foo() - и такой
способ сейчас существует.  А если кому-то нужна библиотека не хуже 17 мартобря,
освященная духом святым - это другое дело.

Смысла характеристики B никакой нету, кроме привязки к модельному времени.

Re: [devel] Q: personal package repositories: user PoV

[Dmitry V. Levin]

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

On Wed, Feb 01, 2012 at 09:47:47PM +0400, Alexey Tourbin wrote:
> On Sat, Jan 28, 2012 at 04:19:39AM +0400, Dmitry V. Levin wrote:
> > 3. Добавление к NSVR пакета еще одной характеристики B.  Автоматическое
> > увеличение этой характеристики самой сборочной системой при каждой
> > пересборке пакета.  Сквозная адаптация всех инструментальных средств на
> > стороне пользователя (в первую очередь apt и rpm) для учета этой
> > характеристики B при обработке пакетов.  Тут возможны различные варианты.
> > Можно включать эту характеристику в имя файла собранного пакета, а можно
> > этого не делать.  Можно включать эту характеристику в пользовательские
> > интерфейсы выбора пакета (например, чтобы можно было указать ее для
> > уточнения пакета при вызове apt-get и rpm), а можно этого не делать.
> > Наконец, можно придумать для этой характеристики B какой-то новый тэг rpm,
> > а можно попробовать адаптировать какой-нибудь из уже существующих.
> > Чем больше будет таких мест, где сможет/будет фигурировать B, тем больше
> > рычагов управления будет у пользователя, с одной стороны, и тем сложнее
> > будет реализация и хуже обратная совместимость, с другой стороны.
> > 
> > 4. На самом деле в rpm уже есть один тэг, который годится на роль такой
> > характеристики B.  Более того, значение этого тэга уже сейчас
> > автоматически увеличивается самой сборочной системой при каждой пересборке
> > пакета.  Более того, этот тэг уже сейчас rpm учитывает при обновлении
> > пакетов именно таким образом, как это нужно для решения нашей задачи: при
> > равенстве NSVR у ранее установленного и предлагаемого для обновления пакета
> > rpm соглашается на обновление, если у обновляемого пакета значение этого
> > тэга больше.  Этот тэг называется BUILDTIME, и его можно получить с
> > помощью rpmquery:
> > $ rpmquery --qf '%{BUILDTIME}\n' -p Sisyphus/files/x86_64/RPMS/rpm-4.0.4-alt100.45.x86_64.rpm 
> > 1327518688
> > Поддержку учета BUILDTIME при обновлении пакетов я добавил в rpm
> > много лет назад, так что можно полагать, что у всех наших пользователей
> > она уже есть.
> 
> Результат сборки пакетов не должен зависеть от модельного времени t,
> а должен зависеть только от ингредиентов, которые напрямую влияют на
> результат сборки.  Таких ингредиентов два: B(S,C)->P, где S - исходный
> код пакета, C - содержимое сборочного чрута.

Время t тоже напрямую (через такие интерфейсы как gettimeofday(2)) может
влиять на результат сборки.  Но суть не в этом.

> Представление о времени в зависимостях вообще нерелевантно, и должно быть
> исключено.  Например, если где-то требуется библиотечная функция foo(),
> то должен быть способ представить зависимость на функцию foo() - и такой
> способ сейчас существует.  А если кому-то нужна библиотека не хуже 17 мартобря,
> освященная духом святым - это другое дело.
> 
> Смысла характеристики B никакой нету, кроме привязки к модельному времени.

Речь идет вообще не о зависимостях, а об обновлении собранных пакетах
как таковых.
Если один и тот же исходный пакет был собран последовательно на разных
состояниях одного и того же репозитория, и даже если обе сборки вполне
совместимы с каждым из этих состояний репозитория, то это не значит, что
эти сборки идентичны.  Поскольку чруты у них различаются, они сами
тоже различаются.  Для rpm они различимы уже много лет, в нем была
реализована возможность различать пакеты с одинаковыми NSVR по
SHA1HEADER и упорядочивать их по BUILDTIME.  А для apt они эквивалентны,
и характеристика B нужна для того, чтобы их различать и упорядочить.

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


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Q: personal package repositories: user PoV

[Alexey Tourbin]

On Wed, Feb 01, 2012 at 10:57:58PM +0400, Dmitry V. Levin wrote:
> > Результат сборки пакетов не должен зависеть от модельного времени t,
> > а должен зависеть только от ингредиентов, которые напрямую влияют на
> > результат сборки.  Таких ингредиентов два: B(S,C)->P, где S - исходный
> > код пакета, C - содержимое сборочного чрута.
> 
> Время t тоже напрямую (через такие интерфейсы как gettimeofday(2)) может
> влиять на результат сборки.  Но суть не в этом.
> 
> > Представление о времени в зависимостях вообще нерелевантно, и должно быть
> > исключено.  Например, если где-то требуется библиотечная функция foo(),
> > то должен быть способ представить зависимость на функцию foo() - и такой
> > способ сейчас существует.  А если кому-то нужна библиотека не хуже 17 мартобря,
> > освященная духом святым - это другое дело.
> > 
> > Смысла характеристики B никакой нету, кроме привязки к модельному времени.
> 
> Речь идет вообще не о зависимостях, а об обновлении собранных пакетах
> как таковых.
> Если один и тот же исходный пакет был собран последовательно на разных
> состояниях одного и того же репозитория, и даже если обе сборки вполне
> совместимы с каждым из этих состояний репозитория, то это не значит, что
> эти сборки идентичны.  Поскольку чруты у них различаются, они сами
> тоже различаются.  Для rpm они различимы уже много лет, в нем была
> реализована возможность различать пакеты с одинаковыми NSVR по
> SHA1HEADER и упорядочивать их по BUILDTIME.  А для apt они эквивалентны,
> и характеристика B нужна для того, чтобы их различать и упорядочить.

Упорядочить по BUILDTIME само по себе никакого смысла нету, можно только
упорядочить (умозрительно) по ингредиентам C, так что пакет, собранный
в чруте С1 с новыми версиями, должен быть "немножко больше" пакета,
собранного в среде C0 со старыми версиями.  Это частичный порядок,
и BUILDTIME плохо его аппроксимирует.

Вообще, для чего всё это нужно?  Кто-то установил предварительную сборку,
а сборочная система потом ещё раз пересобрала пакет, и он автоматически
уже не обновится.  Ну в принципе это достаточно частная проблема, и этот
кто-то - обычно всего один человек.  Если он достаточно хитрый из армян, то
он знает, что надо дальше делать (я в таких случаях иногда делал что-то типа
cd /ALT/Sisyphus/files/x86_64/RPMS && rpm -Fv perl-*.rpm).  Если же он
недостаточно хитрый из армян, то ему и не следовало бы во всё это впутываться.

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

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

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

Но эта система была направлена на строгий учет изменений и контроль
целостности репозитория.  А реализовать ее не удалось, потому что это
требовало сборочных ресурсов, которые оказались фирме альт линукс не по
карману.  Возможно, стратегической ошибкой было и то, что мы не хотели
использовать ccache(1) по крайней мере для тестовой пересборки, а это
могло бы значительно удешевить процесс.

Так вот, видишь, новое слово из будущего - персональные репозитории -
мне не особенно понятно и близко.  Во всяком случае, эти идеи не растут
из требований контроля целостности и строгого учета изменений, в том числе
после тестовой пересборки (которая до сих по не выполняется).  А растут они,
в общем-то, на безрыбье.  Всяк пусть собирает кто что хочет.  Человек -
хозяин своей судьбы и персонального репозитория.  Вольнодумство какое-то. :-)

Re: [devel] Q: personal package repositories: user PoV

[Michael Shigorin]

On Thu, Feb 02, 2012 at 04:36:49AM +0400, Alexey Tourbin wrote:
> Упорядочить по BUILDTIME само по себе никакого смысла нету,
> можно только упорядочить (умозрительно) по ингредиентам C,
> так что пакет, собранный в чруте С1 с новыми версиями, должен
> быть "немножко больше" пакета, собранного в среде C0 со старыми
> версиями.  Это частичный порядок, и BUILDTIME плохо его
> аппроксимирует.

Почему плохо-то?  Для свежесобранных пакетов и базового
репозитория в целом выполняется.

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

Для того, чтоб вместо достаточно частной проблемы можно было
иметь достаточно общее решение (вспомни юзабельность дедала
в плане "ой, забыл отключить").

> Если же он недостаточно хитрый из армян, то ему и не следовало
> бы во всё это впутываться.

Ага, а потом кто-нить будет жаловаться (и небезосновательно)
на отсутствие денег.  При подходе "и пусть они страдают"
это вполне ожидаемо :(

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

Вообще-то это то, что пока мы раскачивались -- уже сделали
и вовсю применяют в Ubuntu и openSUSE.  Только там писали
скорее "в лоб" и вопросы управления получающимися форками,
по отзывам пользователей, не особо продуманы (типичный случай
вида "A есть в репо Ra, B есть в репо Rb, при попытке
задействовать оба получаем конфликт по L").

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

Да посмотри вон ченжлог collectd-5.0.x и подумай, а что если
бы мне было важно сделать бесшовный переезд с автоматической
миграцией данных, как ab@ старался делать для samba -- и тут
библиотеки начинают сновать под ногами, как сговорившись? :)

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

Именно, но в момент мержа кармана в базовый репо накопленные
"фантомные" могут фиксироваться изменением "фактического"
(гругря, release bump с соответствующей записью в changelog
-- либо человеком, работающим над пакетом, либо скриптом,
которому указана тема кармана -- "rebuilt with libZ.so.N").

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

Ну сейчас-то сборочные ресурсы чуть расширились.  И есть мысли
насчёт того, как бы перетащить это всё на ещё более новый уровень
(но пока практических результатов нет).

> Так вот, видишь, новое слово из будущего - персональные
> репозитории - мне не особенно понятно и близко.  Во всяком
> случае, эти идеи не растут из требований контроля целостности
> и строгого учета изменений

Почему?

> в том числе после тестовой пересборки
> (которая до сих по не выполняется).

В смысле результат выбрасывается или ты о чём?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Q: personal package repositories: user PoV

[George V. Kouryachy]

On Thu, Feb 02, 2012 at 04:36:49AM +0400, Alexey Tourbin wrote:
> Упорядочить по BUILDTIME само по себе никакого смысла нету, можно только
> упорядочить (умозрительно) по ингредиентам C, так что пакет, собранный
> в чруте С1 с новыми версиями, должен быть "немножко больше" пакета,
> собранного в среде C0 со старыми версиями.  Это частичный порядок,
> и BUILDTIME плохо его аппроксимирует.
Возможно, существуют условия, внутри которых постоянно увеличивающийся
счётчик всё-таки имеет смысл. Например, для репозитория на git.alt в рамках
одного подновляемого разделяемого задания NSVR+такой счётчик дадут
картину не хуже, чем просто NSVR.

А вот когда репозиториев _несколько_ -- возможны неприятности. Но,
например, если NSVR в этих репозиториях различаются, проблем опять не
должно быть. Возможно, при сборке в карман надо один раз увеличивать
релиз, а затем использовать какой-то счётчик типа BUILDTIME. Или как-то
ранжировать сами репозитории, чтобы при совпадении NSVR выигрывал всегда
один из них, не взирая на BUILDTIME.

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

И в этом смысле возникает ещё один кусок workflow, который непонятно как
зашить в банальное расширение NSVR: человек подключает тестовый
репозиторий, обновляется из него, ничего не работает, он отключает
тестовый репозиторий, и... дальше что? В идеале хотелсь бы снова
обновиться, и всё. То есть, чтобы при наличии репозиториев A и B
побеждали бы пакеты из B, а при одном только A -- пакеты из A.

> Если он достаточно хитрый из армян, то
> cd /ALT/Sisyphus/files/x86_64/RPMS && rpm -Fv perl-*.rpm
Нет-нет, не только. Для начала нужно rsync с git.alt (речь ведь идёт о
расширении возможностей сборочницы, в локальной сборке можно что угодно
намутить и так). Заметим, rsync по timestamp в качестве последнего
сравнения. Затем rpm -F, но не на всех пакетах их rsync-нутого
репозтория (а то вдруг их там стопятьсот), а на свежеобновлённых
(опять-таки вычисляемых по timestamp, если всё остальное внезапно
совпадает). Ergo, в этой процедуре _тоже_ участвует инкрементальный
счётчик. Если не BUILDTIME, то номер сборочной итерации в данном
задании.

-- 
			George V. Kouryachy (aka Fr. Br. George)
			Mailto/JID: george@altlinux.org
			Mobile: (8)9161738325

[devel] ccache(1) to prop things up

[Alexey Tourbin]

On Thu, Feb 02, 2012 at 04:36:49AM +0400, Alexey Tourbin wrote:
> Но эта система была направлена на строгий учет изменений и контроль
> целостности репозитория.  А реализовать ее не удалось, потому что это
> требовало сборочных ресурсов, которые оказались фирме альт линукс не по
> карману.  Возможно, стратегической ошибкой было и то, что мы не хотели
> использовать ccache(1) по крайней мере для тестовой пересборки, а это
> могло бы значительно удешевить процесс.

Когда в 2002 году ab и sb разрабатывали sandman (прототип сборочной
системы), они предлагали, насколько я помню, монтировать внутрь чрута
глобальный раздел с ~/.ccache.  На это есть два возражения.  С точки
зрения безопасности это дает интерференцию между пакетами.  С точки
зрения распределенной архитектуры это требует синхронизацию кеша.

Оба возражения снимаются, если для каждого пакета поддерживать
персональный "сикеш".  Более того, поскольку сборка пакета идет обычно
идет в каталоге ~/RPM/BUILD/%name-%version, а при компиляции с флагом -g
учитываются пути к исходным файлам, то персональный сикеш можно сразу же
ограничить не только именем пакета, но и версией.

То есть можно было бы сделать файлы типа ccache/%name-%version.tar.gz,
и гонять их зад-назад вместе с src.rpm.

Если преследовать еще более строгую схему, которая исключает влияние
сикеша по крайней мере на "настоящие" пакеты, которые поступют в
репозиторий, то можно сделать следующее.  Пакеты всегда собираются
через сикеш.  Сборка "настоящего" пакета (внутри задания) просто
будет выполняться при пустом ~/.ccache (фактически в режиме write-only),
но результат сохраняется для последующих тестовых пересборок (в режиме
read-write).  

Я проделал некоторые замеры.  Повторная сборка elinks с сикешем идет
примерно на 20% быстрее, а повторная сборка apt - в 2 раза.  То есть
наибольшая выгода, очевидно, будет на больших пакетах с Си++ кодом.
В первом приближении (пальцем в небо) сикеш может ускорить тестовую
пересборку репозитория в 2 раза.

Re: [devel] ccache(1) to prop things up

[Alexander Bokovoy]

2012/2/9 Alexey Tourbin <at@altlinux.ru>:
> On Thu, Feb 02, 2012 at 04:36:49AM +0400, Alexey Tourbin wrote:
>> Но эта система была направлена на строгий учет изменений и контроль
>> целостности репозитория.  А реализовать ее не удалось, потому что это
>> требовало сборочных ресурсов, которые оказались фирме альт линукс не по
>> карману.  Возможно, стратегической ошибкой было и то, что мы не хотели
>> использовать ccache(1) по крайней мере для тестовой пересборки, а это
>> могло бы значительно удешевить процесс.
>
> Когда в 2002 году ab и sb разрабатывали sandman (прототип сборочной
> системы), они предлагали, насколько я помню, монтировать внутрь чрута
> глобальный раздел с ~/.ccache.  На это есть два возражения.  С точки
> зрения безопасности это дает интерференцию между пакетами.  С точки
> зрения распределенной архитектуры это требует синхронизацию кеша.
>
> Оба возражения снимаются, если для каждого пакета поддерживать
> персональный "сикеш".  Более того, поскольку сборка пакета идет обычно
> идет в каталоге ~/RPM/BUILD/%name-%version, а при компиляции с флагом -g
> учитываются пути к исходным файлам, то персональный сикеш можно сразу же
> ограничить не только именем пакета, но и версией.
>
> То есть можно было бы сделать файлы типа ccache/%name-%version.tar.gz,
> и гонять их зад-назад вместе с src.rpm.
>
> Если преследовать еще более строгую схему, которая исключает влияние
> сикеша по крайней мере на "настоящие" пакеты, которые поступют в
> репозиторий, то можно сделать следующее.  Пакеты всегда собираются
> через сикеш.  Сборка "настоящего" пакета (внутри задания) просто
> будет выполняться при пустом ~/.ccache (фактически в режиме write-only),
> но результат сохраняется для последующих тестовых пересборок (в режиме
> read-write).
В качестве (не совсем уж и альтернативного) варианта можно
использовать вариацию схемы, которая используется в Fedora. Для каждой
сборочной цели (репозитория) сборочная система ведет кэш базовой
системы ("buildroot"). Этот кэш базовой системы живет несколько
дольше, чем обычно из-за двухстадийной схемы попадания пакетов в
репозитории:  из групп (stable + updates) и (updates-testing) кэш
базовой системы формируется только из первой группы, с возможностью
замещения определенных пакетов в нем собранными, но неотправленными в
репозитории. Стоимость формирования такого кэша для одной архитектуры
-- 5-7 минут, даже если он регенерируется каждый день.

Если мы из используемого при сборке кэша ccache будем собирать разницу
в пакеты foo-ccacheinfo по аналогии с debuginfo, то можно будет
генерировать такой кэш базовой системы и для ccache. Или просто
устанавливать принудительно предыдущую версию foo-ccacheinfo и
зависимости при сборке пакета.

> Я проделал некоторые замеры.  Повторная сборка elinks с сикешем идет
> примерно на 20% быстрее, а повторная сборка apt - в 2 раза.  То есть
> наибольшая выгода, очевидно, будет на больших пакетах с Си++ кодом.
> В первом приближении (пальцем в небо) сикеш может ускорить тестовую
> пересборку репозитория в 2 раза.
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel



-- 
/ Alexander Bokovoy