Re: [devel] [#732] FAILED srpm=exiv2-0.18-alt1.src.rpm

Re: [devel] [#732] FAILED srpm=exiv2-0.18-alt1.src.rpm

[Dmitry V. Levin]

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

On Sun, Feb 15, 2009 at 08:14:41PM +0200, Victor Forsyuk wrote:
[...]
> > *** i586: new unmet dependencies detected
> > dbblast#0.1.8-alt4 libexiv2.so.4
> > geeqie#1.0-alt0.alpha2 libexiv2.so.4
> > gimp-plugin-ufraw#0.14.1-alt1 libexiv2.so.4
> > immix#1.3-alt4 libexiv2.so.4
> > koffice-krita#4:1.9.98.5-alt1 libexiv2.so.4
> > libgwenview#1.4.2-alt6 libexiv2.so.4
> > libgwenview4#4.2.0-alt1 libexiv2.so.4
> > libkexiv2#0.1.7-alt1.1 libexiv2.so.4
> > libkexiv24#4.2.0-alt1 libexiv2.so.4
> > libkritaui#4:1.9.98.5-alt1 libexiv2.so.4
> > python-module-pyexiv2#0.1.2-alt1 libexiv2.so.4
> > qtpfsgui#1.9.2-alt2 libexiv2.so.4
> > rawstudio#1.1.1-alt1 libexiv2.so.4
> > strigi#0.6.3-alt1 libexiv2.so.4
> > ufraw#0.14.1-alt1 libexiv2.so.4
> 
> Это всё замечательно. И эту функциональность (проверку анметов при сборке)
> можно только приветствовать и даже поздравлять с этим действительно полезным
> улучшением. Есть только один вопрос. Каким образом можно указать сборочной
> системе рассматривать это как предупреждения, а не ошибки? Если это еще не
> реализовано, то когда можно ожидать?

Очевидно, что это нарушает дух и букву http://www.altlinux.org/SharedLibsPolicy

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


-- 
ldv

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

Re: [devel] [#732] FAILED srpm=exiv2-0.18-alt1.src.rpm

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

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

On Wed, Feb 18, 2009 at 03:59:48AM +0300, Dmitry V. Levin wrote:

DVL> Может ли существовать какая-нибудь причина для того, чтобы не считать
DVL> порождение анметов ошибкой?

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

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

А практика все зависимости конкретного решения класть в пакет appliance-
мне помогает еще и с учетом установленного syskeeper, благодаря которому я
всегда вижу какие пакеты в системе "левые" -- то есть были установлены не
по цепочке зависимостей от этого appliance.

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

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] [#732] FAILED srpm=exiv2-0.18-alt1.src.rpm

[Ivan Fedorov]

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

Денис Смирнов <mithraen-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org> writes:

> On Wed, Feb 18, 2009 at 03:59:48AM +0300, Dmitry V. Levin wrote:
>
> DVL> Может ли существовать какая-нибудь причина для того, чтобы не считать
> DVL> порождение анметов ошибкой?
>
> Пакеты предназначеные для предоставления зависимостей, которые нужны
> для установки проприетарного ПО? Скажем мог бы быть какой-нибудь
> appliance-utm который для своей установки требовал бы utm.
>
> Это имеет некоторый смысл для выпекания дистрибутивов, использующихся
> только внутри одной организации.
Денис, ну так и храни этот пакет внутри репозитария организации. Зачем
он в сизифе?

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

Re: [devel] [#732] FAILED srpm=exiv2-0.18-alt1.src.rpm

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

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

On Wed, Feb 18, 2009 at 12:27:46PM +0300, Ivan Fedorov wrote:
>> Пакеты предназначеные для предоставления зависимостей, которые нужны
>> для установки проприетарного ПО? Скажем мог бы быть какой-нибудь
>> appliance-utm который для своей установки требовал бы utm.
>> Это имеет некоторый смысл для выпекания дистрибутивов, использующихся
>> только внутри одной организации.
IF> Денис, ну так и храни этот пакет внутри репозитария организации. Зачем
IF> он в сизифе?

Это имеет смысл для тех, кто этим будет пользоваться. К примеру никто не
запрещает от того же tw_cli опубликовать спек :)

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

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

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] [#732] FAILED srpm=exiv2-0.18-alt1.src.rpm

[Igor Vlasenko]

On Wed, Feb 18, 2009 at 03:59:48AM +0300, Dmitry V. Levin wrote:
> > Это всё замечательно. И эту функциональность (проверку анметов при сборке)
> > можно только приветствовать и даже поздравлять с этим действительно полезным
> > улучшением. Есть только один вопрос. Каким образом можно указать сборочной
> > системе рассматривать это как предупреждения, а не ошибки? Если это еще не
> > реализовано, то когда можно ожидать?

> Может ли существовать какая-нибудь причина для того, чтобы не считать
> порождение анметов ошибкой?

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

Например, я в этом месяце обновил maven2, у которого
существенно сменился набор и именование плагинов.

При этом анметы появились в следствие естественной 
смерти (динозавры тоже вымерли).

Всякие серьезные переезды c tetex на strangetex, c X.org на Y.com
естественным образом могут породить анметы.

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

-- 

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

Re: [devel] [#732] FAILED srpm=exiv2-0.18-alt1.src.rpm

[Igor Vlasenko]

On Wed, Feb 18, 2009 at 02:10:25PM +0200, Igor Vlasenko wrote:
> > Может ли существовать какая-нибудь причина для того, чтобы не считать
> > порождение анметов ошибкой?
> 
> переезд с одной платформы на другую, 
> которая существенно отличается.

Другими словами, есть опасность вместе с анметами душить инновации.

-- 

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

Re: [devel] [#732] FAILED srpm=exiv2-0.18-alt1.src.rpm

[Igor Vlasenko]

On Wed, Feb 18, 2009 at 02:17:43PM +0200, Igor Vlasenko wrote:
> On Wed, Feb 18, 2009 at 02:10:25PM +0200, Igor Vlasenko wrote:
> > > Может ли существовать какая-нибудь причина для того, чтобы не считать
> > > порождение анметов ошибкой?
> > 
> > переезд с одной платформы на другую, 
> > которая существенно отличается.
> 
> Другими словами, есть опасность вместе с анметами душить инновации.

Поэтому ручка для пропуска unmets нужна, 
а чтобы ей не злоупотреблять, пусть, например,
ее нажимает incominger после обсуждения в devel@.

-- 

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

Re: [devel] [#732] FAILED srpm=exiv2-0.18-alt1.src.rpm

[Igor Vlasenko]

On Wed, Feb 18, 2009 at 02:19:56PM +0200, Igor Vlasenko wrote:
> Поэтому ручка для пропуска unmets нужна, 
> а чтобы ей не злоупотреблять, пусть, например,
> ее нажимает incominger после обсуждения в devel@.

Так же и с unmets о которых говорил Денис.
Эти можно обрабатывать белыми списками.

Например, Вася Пупкин хочет положить пакет с подстройкой под 
альт какой-то софтины вроде google BlaBla или skype,
c unmet на  google BlaBla (skype-qt).

Пишет в devel@. Если возражений нет, unmet 
добавляется в белый список, и последующие
пакеты с таким unmet на skype-qt молча идут в Сизиф.

-- 

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

Re: [devel] [#732] FAILED srpm=exiv2-0.18-alt1.src.rpm

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

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

On Wed, Feb 18, 2009 at 02:10:25PM +0200, Igor Vlasenko wrote:

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

Что мешает сделать этот переезд в рамках одной транзакции?
Если будут subtask'и, то никаких проблем я не вижу.

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

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

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] [#732] FAILED srpm=exiv2-0.18-alt1.src.rpm

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

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

On Wed, Feb 18, 2009 at 02:25:53PM +0200, Igor Vlasenko wrote:

IV> Так же и с unmets о которых говорил Денис.
IV> Эти можно обрабатывать белыми списками.

Ага. Но без этой фичи обойтись можно. А вот без subtask'ов куда тяжелее.

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

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] FAILED srpm=exiv2-0.18-alt1.src.rpm

[Alexey Tourbin]

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

On Wed, Feb 18, 2009 at 02:10:25PM +0200, Igor Vlasenko wrote:
> On Wed, Feb 18, 2009 at 03:59:48AM +0300, Dmitry V. Levin wrote:
> > Может ли существовать какая-нибудь причина для того, чтобы не считать
> > порождение анметов ошибкой?
> 
> Кроме случая, о котором писал Денис, есть, например, и 
> второй редкий, но очень важный случай - 
> переезд с одной платформы на другую, 
> которая существенно отличается.
> 
> Например, я в этом месяце обновил maven2, у которого
> существенно сменился набор и именование плагинов.
> 
> При этом анметы появились в следствие естественной 
> смерти (динозавры тоже вымерли).
> 
> Всякие серьезные переезды c tetex на strangetex, c X.org на Y.com
> естественным образом могут породить анметы.

Придётся в рамках одного задания чинить все пакеты.
С src.rpm пакетами это будет сделать несколько сложнее,
чем с gear-репозитариями.

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

Re: [devel] FAILED srpm=exiv2-0.18-alt1.src.rpm

[Igor Vlasenko]

On Wed, Feb 18, 2009 at 04:20:14PM +0300, Alexey Tourbin wrote:
> Придётся в рамках одного задания чинить все пакеты.

Это подходит для простого паттерна:
обновилась библиотека - починили клиенты.

Для сложных случаев с многоступенчатым бутстрап-процессом
это не пойдет.

> С src.rpm пакетами это будет сделать несколько сложнее,
> чем с gear-репозитариями.

С src.rpm пакетами сделать одной транзакцией не возможно,
конечно.

Вопрос не в этом. С этими unmets что здесь чему служит?
Суббота для человека или человек для субботы?

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

Когда я выкладывал maven 2.0.7, как раз был переезд, 
пакет первый раз не прошел. Я посовещался с Димой и
мы пришли к выводу, что проще добавить provides в пустышку.

Сам по себе unmet ни плох, ни хорош. Все зависит от контекста 
его появления. Как человек с пистолетом может нарушать порядок,
а может и поддерживать его. А пистолет сам по себе ни хорош ни плох.

А я не робот, чтобы уместить многоступенчатое обновление на 
50-150 пакетов в одну транзакцию. 
А раз в год-полгода у меня такая необходимость возникает :(

-- 

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

Re: [devel] FAILED srpm=exiv2-0.18-alt1.src.rpm

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

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

On Wed, Feb 18, 2009 at 10:09:13PM +0200, Igor Vlasenko wrote:
>> Придётся в рамках одного задания чинить все пакеты.
IV> Это подходит для простого паттерна:
IV> обновилась библиотека - починили клиенты.
IV> Для сложных случаев с многоступенчатым бутстрап-процессом
IV> это не пойдет.

При наличии subtask'ов почему нет?

Собираешь пакеты. Что-то пересобираешь, что-то фиксишь. Что-то
bootstrap'ишь. Но все это -- внутри task'а. Когда процесс бутстрапа
завершен, перекладываешь task в репозиторий.

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

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

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] FAILED srpm=exiv2-0.18-alt1.src.rpm

[Alexey Tourbin]

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

On Wed, Feb 18, 2009 at 10:09:13PM +0200, Igor Vlasenko wrote:
> On Wed, Feb 18, 2009 at 04:20:14PM +0300, Alexey Tourbin wrote:
> > Придётся в рамках одного задания чинить все пакеты.
> 
> Это подходит для простого паттерна:
> обновилась библиотека - починили клиенты.
> 
> Для сложных случаев с многоступенчатым бутстрап-процессом
> это не пойдет.

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

Но в этом же самое время репозитарием пользуются другие люди (а также
на нём собираются пакеты).

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

> > С src.rpm пакетами это будет сделать несколько сложнее,
> > чем с gear-репозитариями.
> 
> С src.rpm пакетами сделать одной транзакцией не возможно,
> конечно.

Вроде бы, можно.  Насколько я знаю, все src.rpm пакеты (одного
мейнтейнера), залитые в incoming за время дельта-тэ, формируют
отдельное задание.  Правда, если задание не проходит, то весь
набор пакетов придётся заливать заново.

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

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

> Когда я выкладывал maven 2.0.7, как раз был переезд, 
> пакет первый раз не прошел. Я посовещался с Димой и
> мы пришли к выводу, что проще добавить provides в пустышку.
> 
> Сам по себе unmet ни плох, ни хорош. Все зависит от контекста 
> его появления. Как человек с пистолетом может нарушать порядок,
> а может и поддерживать его. А пистолет сам по себе ни хорош ни плох.

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

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

> А я не робот, чтобы уместить многоступенчатое обновление на 
> 50-150 пакетов в одну транзакцию. 
> А раз в год-полгода у меня такая необходимость возникает :(

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

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

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

Re: [devel] FAILED srpm=exiv2-0.18-alt1.src.rpm

[REAL]

Денис Смирнов пишет:
> Собираешь пакеты. Что-то пересобираешь, что-то фиксишь. Что-то
> bootstrap'ишь. Но все это -- внутри task'а. Когда процесс бутстрапа
> завершен, перекладываешь task в репозиторий.

Увы, это возможно действительно для банальных случаев. Я вот понимаю 
Игоря, потому что сталкивался с необходимостью обновить версию 
какого-нибудь пакета (скажем, saxon 7.* -> 8.*, в проекте, в котором 
двух версий быть не может и не должно, ибо есть проект-common-xsl, 
которые, в свою очередь, влияют на другие, содержащие 
xslt-преобразования, и так по цепочке). Здесь любая живая система 
требует сквозного контроля и тестирования, иначе лучше и не начинать. 
В данном случае это порождает совершенно непредскакуемые и неочевидные 
грабли, которые обнаруживаются и обезвреживаются именно в процессе 
обновления. Держать у себя весь сизиф локально и пересобирать его с 
каждой новой попыткой пересобрать зависимые пакеты в gear? Это ж 
сколько месяцев на весь процесс будет убиваться? А вот поэтапное 
обновление всё упрощает.

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

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

А здесь просто ещё функционала нужного не хватает. Например, бывает 
нужно ПРЯМО В СИЗИФЕ указать список пакетов (который будет для каждого 
майнтайнера свой, а при операциях все списки - мержиться), чтобы ни 
они, ни зависимые не участвовали в apt-get upgrade/dist-upgdate.

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] FAILED srpm=exiv2-0.18-alt1.src.rpm

[REAL]

Alexey Tourbin пишет:
> Задача состоит в том, чтобы не допускать разлома репозитария вообще,
> то есть допускать только транзакционные обновления пакетов, при которых
> сохраняется целостность репозитария.

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

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

Пересборка пакетов под 100-200 штук, где попадаются объёмом 200 
мегабайт и больше - а не застопорит ли это процесс сборки пакетов для 
остальных майнтайнеров? Насколько упадёт производительность? Насколько 
времени растянется процесс, если такую тестовую пересборку придётся 
запускать раз 20-30?

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

Maven - сам по себе репозиторий (ведь и сама Java - это вовсе не 
просто язык и виртуальная машина, это полноценная платформа для 
разработки и запуска масштабных программных комплексов), и он живёт 
своей жизнью, не только с сизифом, даже с linux зависимостями не 
повязанный. Увы, это реальность. И чтобы хоть как-то облегчить жизнь 
тем, кто пользуется и сизифом, и мавеном одновременно, такие 
масштабные переезды нужны.

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] FAILED srpm=exiv2-0.18-alt1.src.rpm

[Alexey I. Froloff]

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

* REAL <root@> [090219 10:33]:
> Maven - сам по себе репозиторий (ведь и сама Java - это вовсе
> не просто язык и виртуальная машина, это полноценная платформа
> для разработки и запуска масштабных программных комплексов), и
> он живёт своей жизнью,
После подобных высказываний ("мой foo особенный и у него свой
собственный богатый внутренний мир") пропадает всякое желание
пользоваться пакетами этого мантенйера.

-- 
Regards,
Sir Raorn.

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

Re: [devel] FAILED srpm=exiv2-0.18-alt1.src.rpm

[Mikhail Gusarov]

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


Twas brillig at 11:10:05 19.02.2009 UTC+03 when raorn@altlinux.ru did gyre and gimble:

 >> Maven - сам по себе репозиторий (ведь и сама Java - это вовсе
 >> не просто язык и виртуальная машина, это полноценная платформа
 >> для разработки и запуска масштабных программных комплексов), и
 >> он живёт своей жизнью,

 AIF> После подобных высказываний ("мой foo особенный и у него свой
 AIF> собственный богатый внутренний мир") пропадает всякое желание
 AIF> пользоваться пакетами этого мантенйера.

Тебе стоит научиться различать высказывания типа твоей цитаты и типа
real'ового, они не имеют ничего общего.

-- 

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

Re: [devel] FAILED srpm=exiv2-0.18-alt1.src.rpm

[Alexey I. Froloff]

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

* Mikhail Gusarov <dottedmag@> [090219 11:26]:
> Тебе стоит научиться различать высказывания типа твоей цитаты и типа
> real'ового, они не имеют ничего общего.

"""
Rubygems - сам по себе репозиторий (ведь и сам Ruby - это вовсе
не просто язык и виртуальная машина, это полноценная платформа
для разработки и запуска масштабных программных комплексов), и
он живёт своей жизнью,
"""

"""
PyPI - сам по себе репозиторий (ведь и сам Python - это вовсе
не просто язык и виртуальная машина, это полноценная платформа
для разработки и запуска масштабных программных комплексов), и
он живёт своей жизнью,
"""

"""
CPAN - сам по себе репозиторий (ведь и сам Perl - это вовсе
не просто язык и виртуальная машина, это полноценная платформа
для разработки и запуска масштабных программных комплексов), и
он живёт своей жизнью,
"""

Продолжать можно бесконечно.  Как правило это означает "foo не
такой как все и на него не должны действовать общие правила".

-- 
Regards,
Sir Raorn.

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

Re: [devel] FAILED srpm=exiv2-0.18-alt1.src.rpm

[Mikhail Gusarov]

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


Twas brillig at 12:03:16 19.02.2009 UTC+03 when raorn@altlinux.ru did gyre and gimble:

 AIF> Продолжать можно бесконечно.

Можно, только бессмысленно.

 AIF> Как правило это означает "foo не такой как все и на него не должны
 AIF> действовать общие правила".

Это не так.

-- 

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

[devel] [JT] сам себе репозиторий

[Grigory Batalov]

On Thu, 19 Feb 2009 12:03:16 +0300
Alexey I. Froloff wrote:

> """
> CPAN - сам по себе репозиторий (ведь и сам Perl - это вовсе
> не просто язык и виртуальная машина, это полноценная платформа
> для разработки и запуска масштабных программных комплексов), и
> он живёт своей жизнью,
> """

TeXLive - сам по себе дистрибутив (ведь и сам TeX - это вовсе
не просто язык и способ разметки, это полноценная платформа
для разработки и запуска масштабных издательских комплексов), и
он живёт своей жизнью,

=)

> Продолжать можно бесконечно.  Как правило это означает "foo не
> такой как все и на него не должны действовать общие правила".

Re: [devel] [JT] сам себе репозиторий

[Mykola S. Grechukh]

2009/2/19 Grigory Batalov <>:
> On Thu, 19 Feb 2009 12:03:16 +0300
> Alexey I. Froloff wrote:
>
>> """
>> CPAN - сам по себе репозиторий (ведь и сам Perl - это вовсе
>> не просто язык и виртуальная машина, это полноценная платформа
>> для разработки и запуска масштабных программных комплексов), и
>> он живёт своей жизнью,
>> """
>
> TeXLive - сам по себе дистрибутив (ведь и сам TeX - это вовсе
> не просто язык и способ разметки, это полноценная платформа
> для разработки и запуска масштабных издательских комплексов), и
> он живёт своей жизнью,
>
> =)
>
>> Продолжать можно бесконечно.  Как правило это означает "foo не
>> такой как все и на него не должны действовать общие правила".

тогда в репозитарии не должно быть перлового софта, использующего модули CPAN.

Re: [devel] [JT] сам себе репозиторий

[Led]

On Thursday, 19 February 2009 11:27:02 Grigory Batalov wrote:
> On Thu, 19 Feb 2009 12:03:16 +0300
>
> Alexey I. Froloff wrote:
> > """
> > CPAN - сам по себе репозиторий (ведь и сам Perl - это вовсе
> > не просто язык и виртуальная машина, это полноценная платформа
> > для разработки и запуска масштабных программных комплексов), и
> > он живёт своей жизнью,
> > """

Аналогично - Erlang/OTP :)

>
> TeXLive - сам по себе дистрибутив (ведь и сам TeX - это вовсе
> не просто язык и способ разметки, это полноценная платформа
> для разработки и запуска масштабных издательских комплексов), и
> он живёт своей жизнью,

Ну про TeXLive понятно. Он вообще живёт именно СВОЕЙ жизнью, неведомой ни 
пользователям, ни разработчикам Sisyphus:)
- Папа, а TeXLive есть?
- Нет, сынок, это фантастика!

>
> =)
>
> > Продолжать можно бесконечно.  Как правило это означает "foo не
> > такой как все и на него не должны действовать общие правила".


-- 
Led

Re: [devel] [JT] сам себе репозиторий

[Alexey I. Froloff]

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

* Mykola S. Grechukh <nick.grechukh@> [090219 12:36]:
> тогда в репозитарии не должно быть перлового софта,
> использующего модули CPAN.
Странная вещь получается - CPAN/Perl попадают под это
определение, однако в реальной жизни такого вопроса не возникает.
Либо perl не такой уж и особенный, либо остальные, мягко говоря,
слегка преувеличивают.

-- 
Regards,
Sir Raorn.

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

Re: [devel] [JT] сам себе репозиторий

[Igor Vlasenko]

On Thu, Feb 19, 2009 at 11:32:39AM +0200, Led wrote:
> > TeXLive - сам по себе дистрибутив (ведь и сам TeX - это вовсе
> > не просто язык и способ разметки, это полноценная платформа
> > для разработки и запуска масштабных издательских комплексов), и
> > он живёт своей жизнью,
> 
> Ну про TeXLive понятно. Он вообще живёт именно СВОЕЙ жизнью, неведомой ни 
> пользователям, ни разработчикам Sisyphus:)
> - Папа, а TeXLive есть?
> - Нет, сынок, это фантастика!

Хороший пример.
То, что perl или ruby сопровождаются в Сизифе 
хорошо, а, например, TeXLive -- плохо, вовсе не свидетельствует
о том, что майнтайнеры, к примеру, perl или ruby - гении, а
майнтайнеры TeXLive тупые.

Это по сути отражает тот факт, что апстрим perl и ruby
мыслил не только unix-way, но и заложил основы для естественной 
интеграции с дистрибутивами.

А есть апстримы внеземных форм жизни, созданные proprietary Borg mind.
Кто с ними связывался, тот знает.

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

-- 

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

Re: [devel] [JT] сам себе репозиторий

[Led]

On Thursday, 19 February 2009 12:02:39 Igor Vlasenko wrote:
> On Thu, Feb 19, 2009 at 11:32:39AM +0200, Led wrote:
> > > TeXLive - сам по себе дистрибутив (ведь и сам TeX - это вовсе
> > > не просто язык и способ разметки, это полноценная платформа
> > > для разработки и запуска масштабных издательских комплексов), и
> > > он живёт своей жизнью,
> >
> > Ну про TeXLive понятно. Он вообще живёт именно СВОЕЙ жизнью, неведомой ни
> > пользователям, ни разработчикам Sisyphus:)
> > - Папа, а TeXLive есть?
> > - Нет, сынок, это фантастика!
>
> Хороший пример.
> То, что perl или ruby сопровождаются в Сизифе
> хорошо, а, например, TeXLive -- плохо, вовсе не свидетельствует
> о том, что майнтайнеры, к примеру, perl или ruby - гении, а
> майнтайнеры TeXLive тупые.

TeXLive "сопровождается в Сизифе" не плохо. Его попросту нет в Сизифе:)

>
> Это по сути отражает тот факт, что апстрим perl и ruby
> мыслил не только unix-way, но и заложил основы для естественной
> интеграции с дистрибутивами.

Неужели? Прям таки для ALTLinux заточил?

>
> А есть апстримы внеземных форм жизни, созданные proprietary Borg mind.
> Кто с ними связывался, тот знает.
>
> И не надо хвастаться там, где апстрим уже все продумал,
> распилил, разжевал и ложечкой в рот положил.

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

-- 
Led

Re: [devel] [JT] сам себе репозиторий

[Igor Vlasenko]

On Thu, Feb 19, 2009 at 12:08:41PM +0200, Led wrote:
> Вы заблуждаетесь. Впечатление о том, что "апстрим уже все продумал,
u  распилил, разжевал и ложечкой в рот положил" у вас создаётся глядя на пакеты, 
> сборка которых мейнтейнером хорошо продумана и реализована. И, чтобы вы меня 
> не обвинили в "хвастовстве" снова, я имею ввиду вовсе не свои пакеты.

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

> сборка которых мейнтейнером хорошо продумана и реализована.

Опираясь на заложенные апстримом средства.

А если последние отсутствуют?

-- 

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

Re: [devel] [JT] сам себе репозиторий

[Alexey Tourbin]

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

On Thu, Feb 19, 2009 at 12:02:39PM +0200, Igor Vlasenko wrote:
> On Thu, Feb 19, 2009 at 11:32:39AM +0200, Led wrote:
> > > TeXLive - сам по себе дистрибутив (ведь и сам TeX - это вовсе
> > > не просто язык и способ разметки, это полноценная платформа
> > > для разработки и запуска масштабных издательских комплексов), и
> > > он живёт своей жизнью,
> > 
> > Ну про TeXLive понятно. Он вообще живёт именно СВОЕЙ жизнью, неведомой ни 
> > пользователям, ни разработчикам Sisyphus:)
> > - Папа, а TeXLive есть?
> > - Нет, сынок, это фантастика!
> 
> Хороший пример.
> То, что perl или ruby сопровождаются в Сизифе 
> хорошо, а, например, TeXLive -- плохо, вовсе не свидетельствует
> о том, что майнтайнеры, к примеру, perl или ruby - гении, а
> майнтайнеры TeXLive тупые.

При переезде не перл 5.10 придётся пересобирать все бинарные пакеты
(из-за изменения сонейма), а вот совместимость noarch пакетов можно
обеспечить.

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

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

Re: [devel] [JT] сам себе репозиторий

[Led]

On Thursday, 19 February 2009 12:17:14 Igor Vlasenko wrote:
> On Thu, Feb 19, 2009 at 12:08:41PM +0200, Led wrote:
> > Вы заблуждаетесь. Впечатление о том, что "апстрим уже все продумал,
>
> u  распилил, разжевал и ложечкой в рот положил" у вас создаётся глядя на
> пакеты,
>
> > сборка которых мейнтейнером хорошо продумана и реализована. И, чтобы вы
> > меня не обвинили в "хвастовстве" снова, я имею ввиду вовсе не свои
> > пакеты.
>
> Я не вас имел в виду. Здесь достаточно обширная ветка высказываний,
> хотя ответил на последннее сообщение, но это ко всей ветке.
>
> > сборка которых мейнтейнером хорошо продумана и реализована.
>
> Опираясь на заложенные апстримом средства.
>
> А если последние отсутствуют?

Тогда эти средства "закладывает" мейнтейнер. Без претензий своих пакетов 
на "эксклюзивность". Или признаётся (в первую очередь - себе), что собирать 
такие сложные пакеты (апстрим которых не заточил свой софт под ALT) он не 
умеет.

-- 
Led

Re: [devel] [JT] TeXLive

[Grigory Batalov]

On Thu, 19 Feb 2009 11:32:39 +0200
Led wrote:

> > TeXLive - сам по себе дистрибутив (ведь и сам TeX - это вовсе
> > не просто язык и способ разметки, это полноценная платформа
> > для разработки и запуска масштабных издательских комплексов), и
> > он живёт своей жизнью,
> 
> Ну про TeXLive понятно. Он вообще живёт именно СВОЕЙ жизнью, неведомой ни 
> пользователям, ни разработчикам Sisyphus:)
> - Папа, а TeXLive есть?
> - Нет, сынок, это фантастика!

Вообще, некоторые работы ведутся:
http://www.altlinux.org/TeXLivePackaging
http://www.altlinux.org/TeXLiveTesting

На мой неискушённый взгляд, пакетами уже можно пользоваться =).
Обладатели аккаунтов на people.armor.altlinux.org могут присоединиться
к тестированию (там мой git и hasher).
Чем скорее исправим ошибки, тем раньше пакеты попадут в Сизиф.

Re: [devel] FAILED srpm=exiv2-0.18-alt1.src.rpm

[Igor Vlasenko]

On Thu, Feb 19, 2009 at 10:09:26AM +0300, Alexey Tourbin wrote:
> Вы хотите оставить репозитарий в разломанном состоянии "на честном
> слове", что со временем пойдут какие-то многоступенчатые процессы,
> и низшая углеродная фракция реактивного двигателя со временем отпадёт,
> как глазьевская партия "Родина", как несмысленные галаты, которые отпали
> от благодати.
> 
> Но в этом же самое время репозитарием пользуются другие люди (а также
> на нём собираются пакеты).
> 
> Задача состоит в том, чтобы не допускать разлома репозитария вообще,
> то есть допускать только транзакционные обновления пакетов, при которых
> сохраняется целостность репозитария.

Хороший репозитарий = мертвый репозитарий :(

Я повторю, есть опасность вместе с анметами душить инновации.

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

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

И вот допустим до этого времени возникла потребность
что-то обновить. Робот уперся.
И что тогда? Выбрасывать java-пакеты из Сизифа?
В ручном режиме сопровождать больше 100-200 пакетов я не потяну :(

Альтернативно, "заморозить" репозиторий?
Так сказать, трупное окоченение.

Кому нужен стабильный протухший репозитарий?
Кому нужен, тот найдет в загашниках запылившийся 
Mandrake Russian Edition Spring 2001.

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

У перловых пакетов есть 1 соre, 1 система сборки,
1 система поиска библиотек, 1 система зависимостей,
1 соглашение о именовании. 
Счасливы те, кто собирают perl :)

-- 

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

Re: [devel] FAILED srpm=exiv2-0.18-alt1.src.rpm

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

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

On Thu, Feb 19, 2009 at 02:37:46PM +0700, REAL wrote:

R> А сейчас, Вы думаете, что происходит? Как раз период такого 
R> многоступенчатого обновления, но где разлом сизифа, я пока не понимаю. 

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

Это называется -- разломанный репозиторий.

Я понимаю что нужен репозиторий где выполняется bootstrap, поэтапное
исправление, и т.д. Я только не понимаю почему этим репозиторием должен
быть сизиф, а не некие pocket'ы в которых все такие издевательства и
происходят.

Собственное мое предложение таким pocket'ом сделать task'и, добавив в них
subtask и сделав возможность использовать их как самостоятельные
репозитории. Таким образом Игорь, а также любой другой мантейнер сложных
систем где разработчики явно ненавидят мантейнеров дистрибутивов, сможет
одновременно обеспечить себе удобную работу _и_ при этом не мешать жить
пользователям.

R> Игорь недвусмысленно и публично предупреждал, что это будет, и 
R> кое-какие пакеты обновлять не надо. А вот был бы механизм, когда это 
R> дело можно было бы положить на автоматику (не обновлять, что сказали), 
R> а не на память пользователей репозитория - было бы вообще замечательно.

Если пакеты не пригодны для работы, зачем они в _сизифе_?

>> А может быть, если требуются такие "полные переезды", то это значит,
>> что задана слишком жесткая система связей между пакетами?  Для noarch
>> пакетов жесткую систему связей обычно можно немного ослабить.
R> Maven - сам по себе репозиторий (ведь и сама Java - это вовсе не 
R> просто язык и виртуальная машина, это полноценная платформа для 
R> разработки и запуска масштабных программных комплексов), и он живёт 
R> своей жизнью, не только с сизифом, даже с linux зависимостями не 
R> повязанный. Увы, это реальность. И чтобы хоть как-то облегчить жизнь 
R> тем, кто пользуется и сизифом, и мавеном одновременно, такие 
R> масштабные переезды нужны.

Нужность масштабных переездов говорит только о том, что maven -- brain
damaged. Вон ruby team сколько gems отрывала, отрывает, и будет отрывать
:)

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

(Mithraen, откровенно ненавидящий жабу и всю инфраструктуру вокруг нее,
пошел дальше писать на этой самой жабе очередной заказ клиента... Радуясь
тому что Eclipse в настоящий момент в Сизифе более-менее живой)

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

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] [JT] сам себе репозиторий

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

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

On Thu, Feb 19, 2009 at 12:56:07PM +0300, Alexey I. Froloff wrote:

>> тогда в репозитарии не должно быть перлового софта,
>> использующего модули CPAN.
AIF> Странная вещь получается - CPAN/Perl попадают под это
AIF> определение, однако в реальной жизни такого вопроса не возникает.
AIF> Либо perl не такой уж и особенный, либо остальные, мягко говоря,
AIF> слегка преувеличивают.

Думаю дело в проделанной работе. И в объеме необходимой.

У Perl есть CPAN. И есть достаточно небольшой набор стандартных подходов к
созданию пакета, и т.д.

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

По степени "каши в голове" жаба превосходит C/C++, и при этом не имеет
никаких _стандартных_ аналогов soname, symbol versioning и т.д., хотя
каждый маньяк в manifest может изобретать что-то свое на эту тему.

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

Сомнительное удовольствие, я скажу.

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

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] FAILED srpm=exiv2-0.18-alt1.src.rpm

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

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

On Thu, Feb 19, 2009 at 02:30:11PM +0700, REAL wrote:

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

Речь о том, чтобы каждый task сделать таким репозиторием.

>> Вообще бутстрапиться в публичном репо это нехорошо, и приемлимо лишь до
>> тех пор пока нет средств обойтись без этого кошмара.
R> А здесь просто ещё функционала нужного не хватает. Например, бывает 
R> нужно ПРЯМО В СИЗИФЕ указать список пакетов (который будет для каждого 
R> майнтайнера свой, а при операциях все списки - мержиться), чтобы ни 
R> они, ни зависимые не участвовали в apt-get upgrade/dist-upgdate.

Это и называется "разломать репозиторий". Вместо этого нужно ломать -- в
отдельном репозитории и оттуда переносить в Сизиф.

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

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] FAILED srpm=exiv2-0.18-alt1.src.rpm

[Led]

On Thursday, 19 February 2009 18:01:48 Денис Смирнов wrote:
> On Thu, Feb 19, 2009 at 02:37:46PM +0700, REAL wrote:
>
> R> А сейчас, Вы думаете, что происходит? Как раз период такого
> R> многоступенчатого обновления, но где разлом сизифа, я пока не понимаю.
>
> Разлом заключается в том, например, что Игорь иногда предупреждает
> "коллеги -- тут половина жабы неживая, не вздумайте делать
> upgrade/dist-upgrade, а то все у вас взорвется".
>
> Это называется -- разломанный репозиторий.
>
> Я понимаю что нужен репозиторий где выполняется bootstrap, поэтапное
> исправление, и т.д. Я только не понимаю почему этим репозиторием должен
> быть сизиф, а не некие pocket'ы в которых все такие издевательства и
> происходят.

Почему это должны быть "некие pocket'ы", не не локальный рабочий репозитарий 
мейнтейнера? Мне почему-то кажется, что дешевле будет скинутся мейнтейнеру на 
полутерабайтный винчестер для его личного локального "pocket'а"/репозитария, 
чем городить что-то в incoming'е

-- 
Led

Re: [devel] FAILED srpm=exiv2-0.18-alt1.src.rpm

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

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

On Thu, Feb 19, 2009 at 08:46:26PM +0200, Led wrote:

L> Почему это должны быть "некие pocket'ы", не не локальный рабочий репозитарий 
L> мейнтейнера? Мне почему-то кажется, что дешевле будет скинутся мейнтейнеру на 
L> полутерабайтный винчестер для его личного локального "pocket'а"/репозитария, 
L> чем городить что-то в incoming'е

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

Второе -- если изменение затрагивает нескольких мантейнеров, то иначе уже
никак.

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

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] FAILED srpm=exiv2-0.18-alt1.src.rpm

[Igor Vlasenko]

On Thu, Feb 19, 2009 at 07:01:48PM +0300, Денис Смирнов wrote:
> R> А сейчас, Вы думаете, что происходит? Как раз период такого 
> R> многоступенчатого обновления, но где разлом сизифа, я пока не понимаю. 
> 
> Разлом заключается в том, например, что Игорь иногда предупреждает
> "коллеги -- тут половина жабы неживая, не вздумайте делать
> upgrade/dist-upgrade, а то все у вас взорвется".
> 
> Это называется -- разломанный репозиторий.
> 
> Я понимаю что нужен репозиторий где выполняется bootstrap, поэтапное
> исправление, и т.д. Я только не понимаю почему этим репозиторием должен
> быть сизиф, а не некие pocket'ы в которых все такие издевательства и
> происходят.
> 
> Собственное мое предложение таким pocket'ом сделать task'и, добавив в них
> subtask и сделав возможность использовать их как самостоятельные
> репозитории. Таким образом Игорь, а также любой другой мантейнер сложных
> систем где разработчики явно ненавидят мантейнеров дистрибутивов, сможет
> одновременно обеспечить себе удобную работу _и_ при этом не мешать жить
> пользователям.

Это правильное пожелание.
subtask pocket была бы хорошая вещь, будь она написана,
я бы с удовольствием пользовался бы ей там, где это удобно.

Я немного сейчас отвлекусь от темы письма, 
выскажу свое мнение по поводу
введения безусловных ограничений в git.alt.

Не хотелось бы видеть экстремизм вида
Все на utf8!
Все на KDE|Все на Gnome!
Все на tasks!

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

Мне бы сейчас был бы удобнее гибрид tasks + srpm,
команды 
удалить srpm из task,
добавить (переместить) srpm в srpm-based task из другой srpm-based task.

Это только поможет.
Переезд на git.alt произойдет естественно, вследствие
вирусного эффекта.

Не надо дергать этот процесс за уши.

-- 

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

Re: [devel] pockets

[Dmitry V. Levin]

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

On Thu, Feb 19, 2009 at 08:46:26PM +0200, Led wrote:
> On Thursday, 19 February 2009 18:01:48 Денис Смирнов wrote:
> > On Thu, Feb 19, 2009 at 02:37:46PM +0700, REAL wrote:
> >
> > R> А сейчас, Вы думаете, что происходит? Как раз период такого
> > R> многоступенчатого обновления, но где разлом сизифа, я пока не понимаю.
> >
> > Разлом заключается в том, например, что Игорь иногда предупреждает
> > "коллеги -- тут половина жабы неживая, не вздумайте делать
> > upgrade/dist-upgrade, а то все у вас взорвется".
> >
> > Это называется -- разломанный репозиторий.
> >
> > Я понимаю что нужен репозиторий где выполняется bootstrap, поэтапное
> > исправление, и т.д. Я только не понимаю почему этим репозиторием должен
> > быть сизиф, а не некие pocket'ы в которых все такие издевательства и
> > происходят.
> 
> Почему это должны быть "некие pocket'ы", не не локальный рабочий репозитарий 
> мейнтейнера?

Никакие pocket'ы не заменят по удобству локальный рабочий репозиторий.
2Игорь: моё предложение остаётся в силе.


-- 
ldv

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

Re: [devel] FAILED srpm=exiv2-0.18-alt1.src.rpm

[REAL]

Alexey I. Froloff пишет:
> После подобных высказываний ("мой foo особенный и у него свой
> собственный богатый внутренний мир") пропадает всякое желание
> пользоваться пакетами этого мантенйера.

А Вы на яве программируете? Если нет, тогда, думаю, вряд ли 
столкнётесь с пакетами viy@ ;)

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] FAILED srpm=exiv2-0.18-alt1.src.rpm

[REAL]

Денис Смирнов пишет:
> R> Вот был бы дедал по функциональности и аппаратному оснащению идентичен 
> R> сизифу, был бы другой разговор.
> Речь о том, чтобы каждый task сделать таким репозиторием.

Идея вполне здравая, только мне страшно представить, какие 
дополнительные нагрузки на сервера ALT будут периодически обрушиваться 
на длительное время. Хотя я внутреннюю жизнь всего этого хозяйства 
слабо представляю (ибо undocumented), может быть, тут и еженедельные 
сборки ВСЕГО репозитория (кстати, 50000 уже есть или ещё нет :) ) для 
железа что штатный час пик на окраине...

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] [JT] сам себе репозиторий

[Eugene Prokopiev]

19.02.09, Денис Смирнов написал(а):
> On Thu, Feb 19, 2009 at 12:56:07PM +0300, Alexey I. Froloff wrote:
>
>  >> тогда в репозитарии не должно быть перлового софта,
>  >> использующего модули CPAN.
>
> AIF> Странная вещь получается - CPAN/Perl попадают под это
>  AIF> определение, однако в реальной жизни такого вопроса не возникает.
>  AIF> Либо perl не такой уж и особенный, либо остальные, мягко говоря,
>  AIF> слегка преувеличивают.
>
>  Думаю дело в проделанной работе. И в объеме необходимой.
>
>  У Perl есть CPAN. И есть достаточно небольшой набор стандартных подходов к
>  созданию пакета, и т.д.
>
>  А жаба -- это каша. Куча вендоров каждый из которых извращается как может,
>  а мантейнеру потом с этим бардаком разбираться.
>
>  По степени "каши в голове" жаба превосходит C/C++, и при этом не имеет
>  никаких _стандартных_ аналогов soname, symbol versioning и т.д., хотя
>  каждый маньяк в manifest может изобретать что-то свое на эту тему.
>
>  В связи с этим даже в полуавтоматическом режиме сделать из жаба-пакетов
>  что-то приличное невозможно принципиально, то что сейчас делает Игорь --
>  лучшее из того что можно сделать с этим монстром в одиночку. А качества
>  поддержки на уровне того же perl можно достичь только ручной поддержкой
>  каждого из этих пакетов.
>
>  Сомнительное удовольствие, я скажу.

Ты уже раскаялся в том, что я подсадил тебя на это дело? ;)

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

Вот raorn@ много полезного сделал для приведения в порядок ruby - и
спасибо ему. Но какова цена "правильного" запуска реальных приложений
вроде того же Redmine? Такова же цена серьезного использования python
и java - дешевле выходит играть по правилам апстрима :(

Идемте с этим в smoke-room@ :)

-- 
С уважением,
Прокопьев Евгений

Re: [devel] [JT] сам себе репозиторий

[REAL]

Eugene Prokopiev пишет:
> спасибо ему. Но какова цена "правильного" запуска реальных приложений
> вроде того же Redmine? Такова же цена серьезного использования python
> и java - дешевле выходит играть по правилам апстрима :(

Так и делал всегда. Похоже, этим и дальше придётся заниматься, по 
крайней мере, я пока вообще не осознал преимуществ использования maven 
перед привычным подходом. Хотя, наверно, ещё не дошёл до некоторых 
неочевидных нюансов. Времени нет, а тут ещё совсем незнакомый продукт 
ведь.

> Идемте с этим в smoke-room@ :)

Вот интересно: периодически туда посылают, но никто туда не ходит уже 
давно :-D

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] FAILED srpm=exiv2-0.18-alt1.src.rpm

[Alexey Tourbin]

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

On Thu, Feb 19, 2009 at 12:44:30PM +0200, Igor Vlasenko wrote:
> On Thu, Feb 19, 2009 at 10:09:26AM +0300, Alexey Tourbin wrote:
> > Вы хотите оставить репозитарий в разломанном состоянии "на честном
> > слове", что со временем пойдут какие-то многоступенчатые процессы,
> > и низшая углеродная фракция реактивного двигателя со временем отпадёт,
> > как глазьевская партия "Родина", как несмысленные галаты, которые отпали
> > от благодати.
> > 
> > Но в этом же самое время репозитарием пользуются другие люди (а также
> > на нём собираются пакеты).
> > 
> > Задача состоит в том, чтобы не допускать разлома репозитария вообще,
> > то есть допускать только транзакционные обновления пакетов, при которых
> > сохраняется целостность репозитария.

> Хороший репозитарий = мертвый репозитарий :(

Отчасти -- да.  Поэтому некоторые предпочитают сидеть на бранче,
и даже агитируют демагогию про стабильность и нестабильность.  Как бы
избавиться от "стабильности" (хм, то есть от "проблемы стабильности")
и прикрыть пространство для демагогии altogether?

> Я повторю, есть опасность вместе с анметами душить инновации.

Запретив анметы, мы даем взамен механизм заданий и транзакций.
Этого механизма раньше не было, и некоторые анметы были неизбежны.
А теперь всё изменилось.

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

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

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

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

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

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

Заливайте N пакетов поряд.  Это будет задание.  Если задание
обламывается, тогда чините что сломалось, и заливайте N+1 пакет,
N пакетов заново и один новый.  В принципе это будет уже другое задание,
но это эквивалентно добавлению нового gear-репозитария в "нормальное"
задание.  И так пока всё не починится.

> > Робота будет обмануть сложнее, когда тестовая пересборка пакетов
> > станет обязательным условием.
> 
> Гм. IMHO, хотя бы наладить еженедельную пересборку,
> очень уж она ежемесячной выглядит.
> 
> И вот допустим до этого времени возникла потребность
> что-то обновить. Робот уперся.
> И что тогда? Выбрасывать java-пакеты из Сизифа?
> В ручном режиме сопровождать больше 100-200 пакетов я не потяну :(

Зачем надо выбрасывать java-пакеты из Сизифа?  Посмотрите на ситуацию
симметрично: кто-то пытается разломать сборку Джавы.  Из-за этого
его пакеты не прходят, а Джава продолжает нормально собираться.

То есть, когда ситуация наладится, верно будет следующее.  В текущем
состоянии S_k все пакеты устанавливаются и пересобираются.  Каждая
транзакция на основе текущего состояния S_k готовит новое состояние
S_{k+1}.  В новом состоянии все пакеты должны устанавливаться и
пересобираться, иначе транзакция не проходит.

> Альтернативно, "заморозить" репозиторий?
> Так сказать, трупное окоченение.
> 
> Кому нужен стабильный протухший репозитарий?

А кому нужен репозитарий, в котором пакеты не устанавливаются
и не пересобираются?  Это уже не репозитарий, а набор файлов
с расширением *.rpm.

> Кому нужен, тот найдет в загашниках запылившийся 
> Mandrake Russian Edition Spring 2001.

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

Re: [devel] pockets

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

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

On Fri, Feb 20, 2009 at 01:51:13AM +0300, Dmitry V. Levin wrote:

DVL> Никакие pocket'ы не заменят по удобству локальный рабочий репозиторий.
DVL> 2Игорь: моё предложение остаётся в силе.

Одно другому не замена. Нужны как pockets, так и локальный рабочий
репозиторий. У меня их, кстати, несколько.

А для удобства я сейчас собираюсь разворачивать в Сейрос gear-builder.

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

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] FAILED srpm=exiv2-0.18-alt1.src.rpm

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

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

On Fri, Feb 20, 2009 at 11:01:24AM +0700, REAL wrote:
>> После подобных высказываний ("мой foo особенный и у него свой
>> собственный богатый внутренний мир") пропадает всякое желание
>> пользоваться пакетами этого мантенйера.
R> А Вы на яве программируете? Если нет, тогда, думаю, вряд ли 
R> столкнётесь с пакетами viy@ ;)

Даже не программируя на яве приходится сталкиваться с такими вещами как
freemind ;)

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

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] [JT] сам себе репозиторий

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

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

On Fri, Feb 20, 2009 at 08:32:30AM +0300, Eugene Prokopiev wrote:

EP> Ты уже раскаялся в том, что я подсадил тебя на это дело? ;)

Не, в плане бизнеса это проще. А с учетом наличия сейчас gcc4.3-java мне
стало гораздо легче жить (скопилированный бинарник поднимается мгновенно,
в отличии от тяжеловесной виртуальной машины, так что если извращаться на
java теперь даже CGI писать можно).

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

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

Сложный вопрос. Когда я делаю конкретный продукт -- я плюю на
дистрибутивный подход и все необходимые jar'ы встраиваю с помощью proguard
прямо в результирующий пакет. Который потом, если надо, обрабатываю уже
обфускатор и/или компилятором.

Но для работы внутри дистрибутива мне таки удобнее обновлять eclipse
apt-get upgrade'ом а не скачиванием блоба с сайта и установкой в $HOME или
/opt.

EP> Вот raorn@ много полезного сделал для приведения в порядок ruby - и
EP> спасибо ему. Но какова цена "правильного" запуска реальных приложений
EP> вроде того же Redmine? Такова же цена серьезного использования python
EP> и java - дешевле выходит играть по правилам апстрима :(

Например в случае с perl -- получилось просто великолепно. Я давно не
пользовался родной перловой установкой из CPAN. И у меня просто все just
works, а когда не works -- фиксится все считаные минуты.

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

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] FAILED srpm=exiv2-0.18-alt1.src.rpm

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

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

On Thu, Feb 19, 2009 at 11:49:44PM +0200, Igor Vlasenko wrote:

IV> Это правильное пожелание.
IV> subtask pocket была бы хорошая вещь, будь она написана,
IV> я бы с удовольствием пользовался бы ей там, где это удобно.

По поводу твоих слов о том, что требуется полгода для перехода на gear.
Уверен что можно справиться за 2-3 дня, и готов помочь тебе в этом всем
чем возможно.

IV> Не хотелось бы видеть экстремизм вида
IV> Все на utf8!
IV> Все на KDE|Все на Gnome!
IV> Все на tasks!
IV> Сборочная инфраструктура существует для того, чтобы облегчать
IV> жизнь майнтайнера, а не усложнять ее.
IV> Иначе майнтайнеры разбегутся :(

Согласен. Именно поэтому _старый_ подход (с srpm-сборкой) оставили.

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

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] [JT] сам себе репозиторий

[REAL]

Денис Смирнов пишет:
> Но, увы, у меня используется просто множество своих костылей, вместо уже
> существующий в java-мире. Каждый псих изобретает свои костыли, и _это_ в
> мире java мне категорически не нравится.

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

> Сложный вопрос. Когда я делаю конкретный продукт -- я плюю на
> дистрибутивный подход и все необходимые jar'ы встраиваю с помощью proguard
> прямо в результирующий пакет.

А у нас специфика простая: поскольку java у нас работает только на 
сервере (ну вот нефиг ей делать на рабочих станциях!), достаточно все 
нужные jar'ы ложить в ext как на машине разработчика, так и на сервере :)

> Но для работы внутри дистрибутива мне таки удобнее обновлять eclipse
> apt-get upgrade'ом а не скачиванием блоба с сайта и установкой в $HOME или
> /opt.

Да.

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] [JT] сам себе репозиторий

[Eugene Prokopiev]

20.02.09, Денис Смирнов написал(а):
> On Fri, Feb 20, 2009 at 08:32:30AM +0300, Eugene Prokopiev wrote:
>
>  EP> Ты уже раскаялся в том, что я подсадил тебя на это дело? ;)
>
>  Не, в плане бизнеса это проще. А с учетом наличия сейчас gcc4.3-java мне
>  стало гораздо легче жить (скопилированный бинарник поднимается мгновенно,
>  в отличии от тяжеловесной виртуальной машины, так что если извращаться на
>  java теперь даже CGI писать можно).
>
>  Но, увы, у меня используется просто множество своих костылей, вместо уже
>  существующий в java-мире. Каждый псих изобретает свои костыли, и _это_ в
>  мире java мне категорически не нравится.

Ты бы, кстати, как-нибудь описал свои костыли - может еще кому
захочется на них встать ;)

>  EP> Я всегда сомневался в осмысленности дистрибутивного подхода к тому,
>  EP> кто "сам себе репозиторий" - в малых масштабах это оправдано, а чем
>  EP> дальше в лес, тем становится неудобнее прыгать на одной ноге ...
>
>  Сложный вопрос. Когда я делаю конкретный продукт -- я плюю на
>  дистрибутивный подход и все необходимые jar'ы встраиваю с помощью proguard
>  прямо в результирующий пакет. Который потом, если надо, обрабатываю уже
>  обфускатор и/или компилятором.
>
>  Но для работы внутри дистрибутива мне таки удобнее обновлять eclipse
>  apt-get upgrade'ом а не скачиванием блоба с сайта и установкой в $HOME или
>  /opt.

А я до сих пор делаю именно так ...

-- 
С уважением,
Прокопьев Евгений

Re: [devel] FAILED srpm=exiv2-0.18-alt1.src.rpm

[Alexey I. Froloff]

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

* REAL <root@> [090220 06:57]:
> > После подобных высказываний ("мой foo особенный и у него свой
> > собственный богатый внутренний мир") пропадает всякое желание
> > пользоваться пакетами этого мантенйера.
> А Вы на яве программируете? Если нет, тогда, думаю, вряд ли 
> столкнётесь с пакетами viy@ ;)
Я уже давно ничего не программирую, только поддерживаю всё
подряд, написанное на чём попало.

-- 
Regards,
Sir Raorn.

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

Re: [devel] pockets

[Igor Vlasenko]

On Fri, Feb 20, 2009 at 01:51:13AM +0300, Dmitry V. Levin wrote:
> Никакие pocket'ы не заменят по удобству локальный рабочий репозиторий.
> 2Игорь: моё предложение остаётся в силе.

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

Q: "локальный рабочий репозиторий" - это
песочница или там есть какая-то доп. инфраструктура?

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

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

Грубо говоря, у меня есть 2 репо: сизиф и кеш.
Нельзя ли вырезать из builder отдельную утилиту,
которая из этих двух репозиториев sym/hard линковала
новый репозитарий сизиф1, у которого старые версии пакетов 
вытеснены по тому же алгоритму, что и в builder?

Иногда я выкладываю пакеты в сизиф, просто потому, что 
новые пакеты уже не собираются в сизиф + кеш, 
им локально нужен сизиф1, а руками его создавать неудобно,
+ риск что-то пропустить.

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

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

-- 

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

Re: [devel] pockets

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

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

On Fri, Feb 20, 2009 at 05:46:22PM +0200, Igor Vlasenko wrote:

IV> Основная техническая проблема, из-за которой неудобно 
IV> готовить обновление локально, это отсутствие какого-то 
IV> готового инструмента для вытеснения пакетов.
IV> Грубо говоря, у меня есть 2 репо: сизиф и кеш.
IV> Нельзя ли вырезать из builder отдельную утилиту,
IV> которая из этих двух репозиториев sym/hard линковала
IV> новый репозитарий сизиф1, у которого старые версии пакетов 
IV> вытеснены по тому же алгоритму, что и в builder?

+1.

А еще я все-таки попытаюсь сделать ovz с инфраструктурой сборки.
Думаю подобный ovz-профиль многим бы пригодился :)

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

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] FAILED srpm=exiv2-0.18-alt1.src.rpm

[Igor Vlasenko]

On Fri, Feb 20, 2009 at 01:05:12PM +0300, Денис Смирнов wrote:
> По поводу твоих слов о том, что требуется полгода для перехода на gear.
> Уверен что можно справиться за 2-3 дня, и готов помочь тебе в этом всем
> чем возможно.

Речь идет о инфраструктуре для конвеерной обработки
набора git репозитариев.

Понятно, что насоздавать .git репозитариев можно тем же gear-srpmimport в цикле за 10 минут.
Но потом? с ними придется вручную работать?
на 700 пакетов это 700 репо.
на одно только 
$ cd name.git; git-status; head -20 *.spec; sleep 60 while human think about; cd .. 
весь день уйдет :(

Полгода - год имелось в виду, что уйдет на следующего робота:

я нажимаю Большую_Красную_Кнопку, 
робот галопом проходит по всем 700 git репозитариям,
сравнивает их содержимое с новыми поступлениями, 
автоматически импортирует их, корректно распихивая по веткам, 
проставляя теги и прочее, генерирует новые версии, 
скармливает их в hasher, обрабатывает логи, для собравшихся пакетов
прописывает задание для girar-builder и выводит отчет.

Если я доволен, нажимаю Большую_Зеленую_Кнопку :)

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

-- 

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

Re: [devel] srpm->gear

[Dmitry V. Levin]

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

On Fri, Feb 20, 2009 at 09:53:30PM +0200, Igor Vlasenko wrote:
> On Fri, Feb 20, 2009 at 01:05:12PM +0300, Денис Смирнов wrote:
> > По поводу твоих слов о том, что требуется полгода для перехода на gear.
> > Уверен что можно справиться за 2-3 дня, и готов помочь тебе в этом всем
> > чем возможно.
> 
> Речь идет о инфраструктуре для конвеерной обработки
> набора git репозитариев.
> 
> Понятно, что насоздавать .git репозитариев можно тем же gear-srpmimport в цикле за 10 минут.
> Но потом? с ними придется вручную работать?

В крайнем случае можно продолжать работать с srpm-пакетами, а перед
отправкой на сборку делать им gear-srpmimport в цикле.  Да, это не улучшит
workflow, но это и не изменит его.

hint: с помощью gear-srpmimport можно не только создавать новый
gear-репозиторий, но и обновлять уже существующий.


-- 
ldv

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

Re: [devel] pockets

[Dmitry V. Levin]

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

On Fri, Feb 20, 2009 at 05:46:22PM +0200, Igor Vlasenko wrote:
> On Fri, Feb 20, 2009 at 01:51:13AM +0300, Dmitry V. Levin wrote:
> > Никакие pocket'ы не заменят по удобству локальный рабочий репозиторий.
> > 2Игорь: моё предложение остаётся в силе.
> 
> Извиняюсь, что забираю время, но думаю, что ваш ответ 
> будет полезен и другим.
> 
> Q: "локальный рабочий репозиторий" - это
> песочница или там есть какая-то доп. инфраструктура?
> 
> Поясню: у меня сейчас нет особых проблем ни с машиной,
> ни с трафиком. С сизифом я обновляюсь достаточно часто.
> 
> Основная техническая проблема, из-за которой неудобно 
> готовить обновление локально, это отсутствие какого-то 
> готового инструмента для вытеснения пакетов.
> 
> Грубо говоря, у меня есть 2 репо: сизиф и кеш.
> Нельзя ли вырезать из builder отдельную утилиту,
> которая из этих двух репозиториев sym/hard линковала
> новый репозитарий сизиф1, у которого старые версии пакетов 
> вытеснены по тому же алгоритму, что и в builder?

Формализуйте задачу.  Вам вряд ли нужен в точности тот же алгоритм
проверок, который использует
git://git.altlinux.org/people/at/packages/girar-builder

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


-- 
ldv

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

Re: [devel] srpm->gear

[Igor Vlasenko]

On Fri, Feb 20, 2009 at 11:01:08PM +0300, Dmitry V. Levin wrote:
> > Понятно, что насоздавать .git репозитариев можно тем же gear-srpmimport в цикле за 10 минут.
> > Но потом? с ними придется вручную работать?
> 
> В крайнем случае можно продолжать работать с srpm-пакетами, а перед
> отправкой на сборку делать им gear-srpmimport в цикле.  Да, это не улучшит
> workflow, но это и не изменит его.
> 
> hint: с помощью gear-srpmimport можно не только создавать новый
> gear-репозиторий, но и обновлять уже существующий.

Да, но это не дает никакой выгоды, и обременяет доп. операциями.
такой режим - как забивать гвозди микроскопом.

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

Это не сразу, и нужно хорошо продумать, 
но потом это даст существенный выигрыш.

Это как заяц не пил, не курил - велосипед купил.
еще не пил, не курил - мотоцикл купил.
Потом волк на танке приехал - бутылки сдал.

-- 

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

Re: [devel] srpm->gear

[Dmitry V. Levin]

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

On Fri, Feb 20, 2009 at 10:34:40PM +0200, Igor Vlasenko wrote:
> On Fri, Feb 20, 2009 at 11:01:08PM +0300, Dmitry V. Levin wrote:
> > > Понятно, что насоздавать .git репозитариев можно тем же gear-srpmimport в цикле за 10 минут.
> > > Но потом? с ними придется вручную работать?
> > 
> > В крайнем случае можно продолжать работать с srpm-пакетами, а перед
> > отправкой на сборку делать им gear-srpmimport в цикле.  Да, это не улучшит
> > workflow, но это и не изменит его.
> > 
> > hint: с помощью gear-srpmimport можно не только создавать новый
> > gear-репозиторий, но и обновлять уже существующий.
> 
> Да, но это не дает никакой выгоды, и обременяет доп. операциями.
> такой режим - как забивать гвозди микроскопом.

Пока вы не придумаете интерфейс добавлять srpm-файлы прямо в задание,
это даёт выгоду.


-- 
ldv

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

Re: [devel] FAILED srpm=exiv2-0.18-alt1.src.rpm

[Vitaly Lipatov]

On 20 февраля 2009, Денис Смирнов wrote:
> On Fri, Feb 20, 2009 at 11:01:24AM +0700, REAL wrote:
> >> После подобных высказываний ("мой foo особенный и у него
> >> свой собственный богатый внутренний мир") пропадает всякое
> >> желание пользоваться пакетами этого мантенйера.
>
> R> А Вы на яве программируете? Если нет, тогда, думаю, вряд ли
> R> столкнётесь с пакетами viy@ ;)
>
> Даже не программируя на яве приходится сталкиваться с такими
> вещами как freemind ;)
А что с ним? :)


-- 
С уважением,
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

Re: [devel] srpm->gear

[Igor Vlasenko]

On Fri, Feb 20, 2009 at 11:37:36PM +0300, Dmitry V. Levin wrote:
> Пока вы не придумаете интерфейс добавлять srpm-файлы прямо в задание,

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

например, srpm перемещать из другого task.
15:03 - task1: foo.srpm bar.srpm
task1 failed
16:03 - task2: baz.srpm
ssh git.alt task task1 srpm mv task2:baz.srpm
ssh git.alt task task1 run
task1 complete

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


-- 

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

Re: [devel] srpm->gear

[Mikhail Gusarov]

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


Twas brillig at 22:51:37 20.02.2009 UTC+02 when vlasenko@imath.kiev.ua did gyre and gimble:

 IV> и может оказаться полезным майнтайнеру, знакомому с rpm, но
 IV> начинающему в alt.

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

-- 

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

Re: [devel] pockets

[Alexey I. Froloff]

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

* Dmitry V. Levin <ldv@> [090220 23:10]:
> Формализуйте задачу.
В старом пакете sisyphus есть sisyphus_cleanup_dups, только он не
удаляет бинарные пакеты, для которых нет исходных.

В общем хотелось бы видеть отдельным пакетом то, что следит за
содержимым Sisyphus/files/*.  Похоже, это gb-task-commit-repo и
gb-task-repo-plan.  На вход подобному скрипту хочется дать свалку
пакетов и путь до обновляемого files/ (или просто встроить это в
sisyphus?).

-- 
Regards,
Sir Raorn.

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

Re: [devel] pockets

[Dmitry V. Levin]

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

On Sat, Feb 21, 2009 at 12:02:41AM +0300, Alexey I. Froloff wrote:
> * Dmitry V. Levin <ldv@> [090220 23:10]:
> > Формализуйте задачу.
> В старом пакете sisyphus есть sisyphus_cleanup_dups, только он не
> удаляет бинарные пакеты, для которых нет исходных.
> 
> В общем хотелось бы видеть отдельным пакетом то, что следит за
> содержимым Sisyphus/files/*.  Похоже, это gb-task-commit-repo и
> gb-task-repo-plan.

Да.

> На вход подобному скрипту хочется дать свалку
> пакетов и путь до обновляемого files/ (или просто встроить это в
> sisyphus?).

Вопрос, по каким правилам?
В gb-task-* зашиты довольно жёсткие правила.


-- 
ldv

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

Re: [devel] pockets

[Igor Vlasenko]

On Sat, Feb 21, 2009 at 12:02:41AM +0300, Alexey I. Froloff wrote:
> * Dmitry V. Levin <ldv@> [090220 23:10]:
> > Формализуйте задачу.
> В старом пакете sisyphus есть sisyphus_cleanup_dups, только он не
> удаляет бинарные пакеты, для которых нет исходных.
> 
> В общем хотелось бы видеть отдельным пакетом то, что следит за
> содержимым Sisyphus/files/*.  Похоже, это gb-task-commit-repo и
> gb-task-repo-plan.  На вход подобному скрипту хочется дать свалку
> пакетов и путь до обновляемого files/ (или просто встроить это в
> sisyphus?).

или даже на вход подать листинги свалок rpm файлов
а на выводе получить фильтрованный список


-- 

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

Re: [devel] pockets

[Alexey I. Froloff]

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

* Dmitry V. Levin <ldv@> [090221 00:12]:
> > На вход подобному скрипту хочется дать свалку пакетов и путь
> > до обновляемого files/ (или просто встроить это в sisyphus?).
> Вопрос, по каким правилам?
> В gb-task-* зашиты довольно жёсткие правила.
Мне достаточно "один src.rpm per %{NAME} распоследней версии" и
"$arch.rpm только те, для которых остались src.rpm после п.1".

-- 
Regards,
Sir Raorn.

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

Re: [devel] FAILED srpm=exiv2-0.18-alt1.src.rpm

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

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

On Fri, Feb 20, 2009 at 11:51:26PM +0300, Vitaly Lipatov wrote:
>> Даже не программируя на яве приходится сталкиваться с такими
>> вещами как freemind ;)
VL> А что с ним? :)

С ним вроде сейчас все хорошо :) Просто он -- тоже жаба :)

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

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

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] pockets

[REAL]

Денис Смирнов пишет:
> А еще я все-таки попытаюсь сделать ovz с инфраструктурой сборки.
> Думаю подобный ovz-профиль многим бы пригодился :)

Вот это было бы просто замечательно!

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ