[devel] I: arepo: next steps

[devel] I: arepo: next steps

[Igor Vlasenko]

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

В общем, так понимаю, arepo стагнировал, а это вещь нужная.
Решил, раз нет возражений, заняться arepo плотнее.

Что уже сделано:
подготовил патчи к arepo, добавляющие 
1) поддержку репозиториев без noarch компоненты (по просьбе Сергея)
2) модульный конфиг-файл для arepo, c директивой "include: |"
Отличие от прототипа в том, что поменял тип строки yaml c '>' на '|',
т.е. есть возможность задать пути с пробелами внутри.

include: |
   /home/vpupkin/Рабочий Стол/NX-client-arepo-t6.conf

Повесил заявку 
http://bugzilla.altlinux.org/show_bug.cgi?id=26985
надеюсь, эти изменения скоро будут в Сизифе.

Что хочу сделать:

I. распрямить работу arepo с apt.

arepo сейчас, чтобы узнать EPOCH-VERSION-RELEASE пакета NAME,
создает aptbox и выполняет
 apt-get install --yes --print-uris NAME
Если apt-get install завершился успешно, получаем путь к rpm
файлу в локальной файловой системе, затем открываем полученный
rpm файл с помощью python-rpm и извлекаем значения из RPM Header'а.

Это и слишком медленный путь, и слишком глючный.

Симптомы глюка:
В t6 обновился libpng12. Ожидалось, что arepo пересоберет
i586-libpng12. Однако arepo пересобрал не только i586-libpng12,
но и около 30 других пакетов, именно все имевшиеся зависящие от
i586-libpng12 пакеты, включая wine, поскольку из-за несоответствия
версий libpng12 и i586-libpng12 они оказались не устанавливаемыми 
и apt-get install --yes --print-uris завершался для них неуспешно.

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

II. вырезать из arepo.py низкоуровневую работу с rpm в отдельный
скрипт.

Собственно arepo.py пусть и дальше занимается тем, чем и занимался,
т.е. созданием и обновлением x86_32 репозитория,
а отдельный скрипт araperpm, rpm2arepo или как его назвать.py
будет заниматься конкретно созданием 
i586-name-V-R.src.rpm из name-V-R.i586.rpm.

Это не повлияет на производительность, так как специфика питона -
что любой скрипт легко выступает в роли библиотеки.
И arepo будет просто загружать rpm2arepo.py как свою библиотеку.

Это и существенно упростит отладку, и, главное, встраивать в
сборочницу весь arepo смысла не имеет, сборочнице нужна только
функциональность rpm2arepo.py. Все остальное - сборка пакетов
и менеджмент репозиториев - в сборочнице уже есть, имеющаяся
высокоуровневая часть arepo - это по сути дублирование скриптов сборчницы,
но не полное, недостаточного качества и написанное на python.

Мое предложение -- arepo надо разрезать на две части 
и встраивать в сборчницу сразу низкоуровневый скрипт конверсии rpm,
условное название rpm2arepo.py.


-- 

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

Re: [devel] I: arepo: next steps

[Dmitry V. Levin]

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

Hi,

On Mon, Feb 27, 2012 at 08:13:16PM +0200, Igor Vlasenko wrote:
> Уважаемые коллеги,
> 
> В общем, так понимаю, arepo стагнировал, а это вещь нужная.

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

Можно дать этой части сборочницы имя arepo, можно не давать названия, сути
это не меняет.

На эту тему у нас есть следующие мысли.

У этого условного girar-builder-arepo, очевидно, будет совсем другая
архитектура.  Его роль - во время обработки задания, по окончании
тестирования нового состояния репозитория автоматически определить, какие
arepo-пакеты нужно создать, сгенерировать эти пакеты, и сформировать новое
состояние arepo-репозитория.

Определение пакетов определяется следующими принципами:
- noarch-пакеты не участвуют в рассмотрении;
- пакеты обрабатываются по одной из двух схем:
  + arepo-библиотеки: если i586.rpm и x86_64.rpm отличаются по составу
    файлов в каталоге /usr/lib, то в arepo-пакет попадают все файлы из
    каталога /usr/lib пакета i586.rpm, которых нет в пакете x86_64.rpm;
  + arepo-программы: если x86_64.rpm нет (или он есть, но нам заранее
    известно, что его не следует учитывать), то в arepo-пакет попадают
    все файлы из пакета i586.rpm; 
- пустые arepo-пакеты не создаются.

Зависимости arepo-библиотек вычисляются следующим образом:
- requires:
  + копируются все set-version-зависимости из i586.rpm;
  + добавляется NEVR-зависимость на x86_64.rpm;
- provides:
  + копируются все set-version-зависимости из i586.rpm;
  + добавляется стандартная self-NEVR-зависимость;

Зависимости arepo-программ вычисляются следующим образом:
- requires:
  + к зависимостям на имена пакетов, которые есть в новом состоянии
    arepo-репозитория, добавляется arepo-префикс;
  + остальные зависимости копируются из i586.rpm без изменений;
- provides:
  + копируется все без изменений, за исключением self-NEVR-зависимости,
    вместо которой добавляется своя стандартная.

Хочется обойтись простым перекладыванием заголовков и файлов, без
использования rpmbuild'а и прочих вычислений произвольного кода в
изолированной среде.

Все это пока что мысли, которые еще предстоит проверить на практике.


-- 
ldv

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

Re: [devel] I: arepo: next steps

[Michael Shigorin]

On Tue, Feb 28, 2012 at 03:42:09AM +0400, Dmitry V. Levin wrote:
> Хочется обойтись простым перекладыванием заголовков и файлов,
> без использования rpmbuild'а и прочих вычислений произвольного
> кода в изолированной среде.

rpmrebuild не смотрел часом?

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

Re: [devel] I: arepo: next steps

[Vitaly Kuznetsov]

On Tue, 28 Feb 2012 03:42:09 +0400, Dmitry V. Levin wrote:
> Hi,
>
> On Mon, Feb 27, 2012 at 08:13:16PM +0200, Igor Vlasenko wrote:
>> Уважаемые коллеги,
>>
>> В общем, так понимаю, arepo стагнировал, а это вещь нужная.
>
> Есть другая точка зрения: репозиторий, который сейчас называется 
> сейчас
> x86_32 (и который на всякий случай предстоит переименовать во 
> избежание
> коллизий с настоящим x86_32) - это вещь нужная, но его формированием
> должна заниматься та же самая система, которая обрабатывает задания, 
> чтобы
> обеспечить должную актуальность, полноту и целостность этого 
> репозитория.
> ...

Hi,

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

Re: [devel] I: arepo: next steps

[Dmitry V. Levin]

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

On Tue, Feb 28, 2012 at 03:42:09AM +0400, Dmitry V. Levin wrote:
> Зависимости arepo-библиотек вычисляются следующим образом:
> - requires:
>   + копируются все set-version-зависимости из i586.rpm;

  + зависимости на имена пакетов, которые есть в новом состоянии
    arepo-репозитория, копируются с добавлением arepo-префикса;


-- 
ldv

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

Re: [devel] I: arepo: next steps

[Igor Vlasenko]

On Tue, Feb 28, 2012 at 03:42:09AM +0400, Dmitry V. Levin wrote:
> Есть другая точка зрения: репозиторий, который сейчас называется сейчас
> x86_32 (и который на всякий случай предстоит переименовать во избежание
> коллизий с настоящим x86_32) - это вещь нужная, но его формированием
> должна заниматься та же самая система, которая обрабатывает задания, чтобы
> обеспечить должную актуальность, полноту и целостность этого репозитория.

Почему другая точка зрения? Я и сам так думаю. :)
Просто доступа к сборочнице у меня нет, и все, что я мог предложить -
работу с имеющимся arepo.

-- 

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

Re: [devel] I: arepo: next steps

[Igor Vlasenko]

On Tue, Feb 28, 2012 at 04:32:57PM +0400, Vitaly Kuznetsov wrote:
> спасибо, это как раз то, что я хотел написать. Я попробую в
> ближайшее время поиграться с python-rpm и понять, можем ли бы им
> сформировать правильную rpm-ку. Если сможем, то мы получим очень
> приличную скорость. Это важно как минимум для бутстрапа (когда мы
> будем перепаковывать весь репозитоий).

О, замечательно. В этом случае, мне, наверное, 
нет смысла копаться в коде arepo-1, который вскоре,
похоже, полностью устареет.

Будем ждать arepo-2 :)


-- 

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

Re: [devel] I: arepo: next steps

[Vitaly Kuznetsov]

On Tue, 28 Feb 2012 19:41:15 +0200, Igor Vlasenko wrote:
> On Tue, Feb 28, 2012 at 04:32:57PM +0400, Vitaly Kuznetsov wrote:
>> спасибо, это как раз то, что я хотел написать. Я попробую в
>> ближайшее время поиграться с python-rpm и понять, можем ли бы им
>> сформировать правильную rpm-ку. Если сможем, то мы получим очень
>> приличную скорость. Это важно как минимум для бутстрапа (когда мы
>> будем перепаковывать весь репозитоий).
>
> О, замечательно. В этом случае, мне, наверное,
> нет смысла копаться в коде arepo-1, который вскоре,
> похоже, полностью устареет.
>
> Будем ждать arepo-2 :)

В взглянул на python-rpm и rpmrebuild. Первый, похоже, вообще не имеет 
интерфейса для записи заголовков rpm. Второй решает немного другую 
задачу - восстанавливает rpm из установленного состояния (т.е. 
проворачивает фарш обратно).
Нам нужен немного другой инструмент: взять rpm-файл, отредактировать 
заголовки и содержимое, сохранить как новый rpm-файл. Мне пока такой 
найти не удалось. Вижу два возможных варианта решения:
1) Реализовать такой инструмент на librpm-е (муторно)
2) Таки билдить результирующий rpm с помощью rpmbuild-а. В общем случае 
данный подход требует новой хешерницы для каждого пакета, но мы можем 
использовать дополнительное знание о том, что спек-файл является вовсе 
не произвольным, а только что нами сформированным. Его можно попытаться 
сформировать таким образом, чтобы никакого выполнения произвольного кода 
не происходило (выписываем все Requires/Provides вручную, глушим все 
автопоисковики,...). Тогда будет возможно всю перепаковку для всей 
репозиторной транзакции (или вообще для всего репозитория в период 
бутстрапа) выполнить последовательно в одной и той же хешернице: создаём 
спек, специальным образом извлекаем файлы из исходного пакета, формируем 
новый пакет. Это должно быть достаточно быстро.

Re: [devel] I: arepo: next steps

[Led]

On Tuesday 28 February 2012 20:59:42 Vitaly Kuznetsov wrote:
> On Tue, 28 Feb 2012 19:41:15 +0200, Igor Vlasenko wrote:
> > On Tue, Feb 28, 2012 at 04:32:57PM +0400, Vitaly Kuznetsov wrote:
> >> спасибо, это как раз то, что я хотел написать. Я попробую в
> >> ближайшее время поиграться с python-rpm и понять, можем ли бы им
> >> сформировать правильную rpm-ку. Если сможем, то мы получим очень
> >> приличную скорость. Это важно как минимум для бутстрапа (когда мы
> >> будем перепаковывать весь репозитоий).
> >
> > О, замечательно. В этом случае, мне, наверное,
> > нет смысла копаться в коде arepo-1, который вскоре,
> > похоже, полностью устареет.
> >
> > Будем ждать arepo-2 :)
>
> В взглянул на python-rpm и rpmrebuild. Первый, похоже, вообще не имеет
> интерфейса для записи заголовков rpm. Второй решает немного другую
> задачу - восстанавливает rpm из установленного состояния (т.е.
> проворачивает фарш обратно).
> Нам нужен немного другой инструмент: взять rpm-файл, отредактировать
> заголовки и содержимое, сохранить как новый rpm-файл.

Вот как раз это rpmrebuild и делает.

-- 
Led

Re: [devel] I: arepo: next steps

[Vitaly Kuznetsov]

On Tue, 28 Feb 2012 21:08:35 +0200, Led wrote:
> On Tuesday 28 February 2012 20:59:42 Vitaly Kuznetsov wrote:
>> On Tue, 28 Feb 2012 19:41:15 +0200, Igor Vlasenko wrote:
>> > On Tue, Feb 28, 2012 at 04:32:57PM +0400, Vitaly Kuznetsov wrote:
>> >> спасибо, это как раз то, что я хотел написать. Я попробую в
>> >> ближайшее время поиграться с python-rpm и понять, можем ли бы им
>> >> сформировать правильную rpm-ку. Если сможем, то мы получим очень
>> >> приличную скорость. Это важно как минимум для бутстрапа (когда мы
>> >> будем перепаковывать весь репозитоий).
>> >
>> > О, замечательно. В этом случае, мне, наверное,
>> > нет смысла копаться в коде arepo-1, который вскоре,
>> > похоже, полностью устареет.
>> >
>> > Будем ждать arepo-2 :)
>>
>> В взглянул на python-rpm и rpmrebuild. Первый, похоже, вообще не 
>> имеет
>> интерфейса для записи заголовков rpm. Второй решает немного другую
>> задачу - восстанавливает rpm из установленного состояния (т.е.
>> проворачивает фарш обратно).
>> Нам нужен немного другой инструмент: взять rpm-файл, отредактировать
>> заголовки и содержимое, сохранить как новый rpm-файл.
>
> Вот как раз это rpmrebuild и делает.

Я правильно понимаю, что мы говорим о 
http://sourceforge.net/projects/rpmrebuild/ ? "rpmrebuild is a tool to 
build an RPM file from a package that has already been installed." Он 
правда умеет работать с неустановленными rpm-ами? Если да, то это очень 
интересно, можно не изобретать очередной велосипед. Если нет, то не 
проканает: на каждый пакет потребуется отдельная хешерница, установка 
зависимостей, ... -- это может быть достаточно долго.

Re: [devel] I: arepo: next steps

[Led]

On Tuesday 28 February 2012 22:38:23 Vitaly Kuznetsov wrote:
> On Tue, 28 Feb 2012 21:08:35 +0200, Led wrote:
> > On Tuesday 28 February 2012 20:59:42 Vitaly Kuznetsov wrote:
> >> On Tue, 28 Feb 2012 19:41:15 +0200, Igor Vlasenko wrote:
> >> > On Tue, Feb 28, 2012 at 04:32:57PM +0400, Vitaly Kuznetsov wrote:
> >> >> спасибо, это как раз то, что я хотел написать. Я попробую в
> >> >> ближайшее время поиграться с python-rpm и понять, можем ли бы им
> >> >> сформировать правильную rpm-ку. Если сможем, то мы получим очень
> >> >> приличную скорость. Это важно как минимум для бутстрапа (когда мы
> >> >> будем перепаковывать весь репозитоий).
> >> >
> >> > О, замечательно. В этом случае, мне, наверное,
> >> > нет смысла копаться в коде arepo-1, который вскоре,
> >> > похоже, полностью устареет.
> >> >
> >> > Будем ждать arepo-2 :)
> >>
> >> В взглянул на python-rpm и rpmrebuild. Первый, похоже, вообще не
> >> имеет
> >> интерфейса для записи заголовков rpm. Второй решает немного другую
> >> задачу - восстанавливает rpm из установленного состояния (т.е.
> >> проворачивает фарш обратно).
> >> Нам нужен немного другой инструмент: взять rpm-файл, отредактировать
> >> заголовки и содержимое, сохранить как новый rpm-файл.
> >
> > Вот как раз это rpmrebuild и делает.
>
> Я правильно понимаю, что мы говорим о
> http://sourceforge.net/projects/rpmrebuild/ ? "rpmrebuild is a tool to
> build an RPM file from a package that has already been installed." Он
> правда умеет работать с неустановленными rpm-ами? Если да, то это очень
> интересно, можно не изобретать очередной велосипед. Если нет, то не
> проканает: на каждый пакет потребуется отдельная хешерница, установка
> зависимостей, ... -- это может быть достаточно долго.

Я правильно понимаю, что выполнить

apt-get install rpmrebuild
man rpmrebuild

- это очень сложная для вас задача?

-- 
Led

Re: [devel] I: arepo: next steps

[Michael Shigorin]

On Tue, Feb 28, 2012 at 11:33:23PM +0200, Led wrote:
> > Я правильно понимаю, что мы говорим о
> > http://sourceforge.net/projects/rpmrebuild/ ? "rpmrebuild is
> > a tool to build an RPM file from a package that has already
> > been installed." Он правда умеет работать с неустановленными
> > rpm-ами? Если да, то это очень интересно, можно не изобретать

-p

> Я правильно понимаю, что выполнить [...] man rpmrebuild

Саш, если у софтины кривоватое описание на сайте,
а ты прочёл и знаешь -- продуктивней сразу подсказать,
что "да" и в какую сторону читать.

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

Re: [devel] I: arepo: next steps

[Dmitry V. Levin]

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

On Tue, Feb 28, 2012 at 11:33:23PM +0200, Led wrote:
> On Tuesday 28 February 2012 22:38:23 Vitaly Kuznetsov wrote:
> > On Tue, 28 Feb 2012 21:08:35 +0200, Led wrote:
[...]
> > > Вот как раз это rpmrebuild и делает.
> >
> > Я правильно понимаю, что мы говорим о
> > http://sourceforge.net/projects/rpmrebuild/ ? "rpmrebuild is a tool to
> > build an RPM file from a package that has already been installed." Он
> > правда умеет работать с неустановленными rpm-ами? Если да, то это очень
> > интересно, можно не изобретать очередной велосипед. Если нет, то не
> > проканает: на каждый пакет потребуется отдельная хешерница, установка
> > зависимостей, ... -- это может быть достаточно долго.
> 
> Я правильно понимаю, что выполнить
> 
> apt-get install rpmrebuild
> man rpmrebuild
> 
> - это очень сложная для вас задача?

Это несекъюрно, мы предпочитаем
$ hsh-install man rpmrebuild && hsh-run --pty man rpmrebuild
:-)

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


-- 
ldv

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

Re: [devel] I: arepo: next steps

[Led]

On Wednesday 29 February 2012 00:23:16 Dmitry V. Levin wrote:
> On Tue, Feb 28, 2012 at 11:33:23PM +0200, Led wrote:
> > On Tuesday 28 February 2012 22:38:23 Vitaly Kuznetsov wrote:
> > > On Tue, 28 Feb 2012 21:08:35 +0200, Led wrote:
>
> [...]
>
> > > > Вот как раз это rpmrebuild и делает.
> > >
> > > Я правильно понимаю, что мы говорим о
> > > http://sourceforge.net/projects/rpmrebuild/ ? "rpmrebuild is a tool to
> > > build an RPM file from a package that has already been installed." Он
> > > правда умеет работать с неустановленными rpm-ами? Если да, то это очень
> > > интересно, можно не изобретать очередной велосипед. Если нет, то не
> > > проканает: на каждый пакет потребуется отдельная хешерница, установка
> > > зависимостей, ... -- это может быть достаточно долго.
> >
> > Я правильно понимаю, что выполнить
> >
> > apt-get install rpmrebuild
> > man rpmrebuild
> >
> > - это очень сложная для вас задача?
>
> Это несекъюрно, мы предпочитаем
> $ hsh-install man rpmrebuild && hsh-run --pty man rpmrebuild
>
> :-)
>
> Поскольку rpmrebuild существенным образом использует rpmbuild, я считаю
> этот подход небезопасным.  Используемый в rpmrebuild метод - сдампить все
> необходимое в спек, а потом выполнить rpmbuild - это довольно рискованная
> процедура с точки зрения выполнения произвольного кода.  В нынешней
> реализации не видно попыток с этим бороться путем квотирования всего и
> вся, и я, честно говоря, не уверен, что нам стоит идти этим путем.

Какой "произвольный код" может оказаться в преамбуле и секции %files спека?
Секций %prep, %build, %install в этом спеке отсутствуют или же их можно принудительно обнулить.
Или я не понимаю о чём вы гворите -
hsh-install man _что_ && hsh-run --pty man _что_
прочитать?:)

-- 
Led

Re: [devel] I: arepo: next steps

[Dmitry V. Levin]

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

On Wed, Feb 29, 2012 at 12:34:39AM +0200, Led wrote:
> On Wednesday 29 February 2012 00:23:16 Dmitry V. Levin wrote:
[...]
> > Поскольку rpmrebuild существенным образом использует rpmbuild, я считаю
> > этот подход небезопасным.  Используемый в rpmrebuild метод - сдампить все
> > необходимое в спек, а потом выполнить rpmbuild - это довольно рискованная
> > процедура с точки зрения выполнения произвольного кода.  В нынешней
> > реализации не видно попыток с этим бороться путем квотирования всего и
> > вся, и я, честно говоря, не уверен, что нам стоит идти этим путем.
> 
> Какой "произвольный код" может оказаться в преамбуле и секции %files спека?

Например, любой текстовый тэг может содержать %макрос и вообще
произвольный %(код); некоторые из них не пройдут проверку sisyphus_check'ом
на более ранней стадии, но такие тэги как %summary, %description, %url,
%files могут содержать почти что угодно.  Понятно, что их все, наверное,
можно заквотить, но сам факт использования rpmbuild, который фактически
делает eval, открывает разные возможности, не все их которых я могу
назвать навскидку.


-- 
ldv

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

Re: [devel] I: arepo: next steps

[Led]

On Wednesday 29 February 2012 01:04:33 Dmitry V. Levin wrote:
> On Wed, Feb 29, 2012 at 12:34:39AM +0200, Led wrote:
> > On Wednesday 29 February 2012 00:23:16 Dmitry V. Levin wrote:
>
> [...]
>
> > > Поскольку rpmrebuild существенным образом использует rpmbuild, я считаю
> > > этот подход небезопасным.  Используемый в rpmrebuild метод - сдампить
> > > все необходимое в спек, а потом выполнить rpmbuild - это довольно
> > > рискованная процедура с точки зрения выполнения произвольного кода.  В
> > > нынешней реализации не видно попыток с этим бороться путем квотирования
> > > всего и вся, и я, честно говоря, не уверен, что нам стоит идти этим
> > > путем.
> >
> > Какой "произвольный код" может оказаться в преамбуле и секции %files
> > спека?
>
> Например, любой текстовый тэг может содержать %макрос и вообще
> произвольный %(код);

rpmrebuild экранирует все '%' в генерируемом спеке.

> некоторые из них не пройдут проверку sisyphus_check'ом 
> на более ранней стадии, но такие тэги как %summary, %description, %url,
> %files могут содержать почти что угодно.  Понятно, что их все, наверное,
> можно заквотить, но сам факт использования rpmbuild, который фактически
> делает eval, открывает разные возможности, не все их которых я могу
> назвать навскидку.

-- 
Led

Re: [devel] I: arepo: next steps

[Vitaly Kuznetsov]

On Tue, 28 Feb 2012 23:33:23 +0200, Led wrote:
>
> Я правильно понимаю, что выполнить
>
> apt-get install rpmrebuild
> man rpmrebuild
>
> - это очень сложная для вас задача?

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

Re: [devel] I: arepo: next steps

[Michael Shigorin]

On Wed, Feb 29, 2012 at 10:09:39AM +0400, Vitaly Kuznetsov wrote:
> Но если ответить на прямой вопрос так сложно,
> то я не очень понимаю, зачем советовать инструмент.

Посоветовал я и, чгря, не ожидал такого.

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

Re: [devel] I: arepo: next steps

[Led]

On Wednesday 29 February 2012 08:09:39 Vitaly Kuznetsov wrote:
> On Tue, 28 Feb 2012 23:33:23 +0200, Led wrote:
> > Я правильно понимаю, что выполнить
> >
> > apt-get install rpmrebuild
> > man rpmrebuild
> >
> > - это очень сложная для вас задача?
>
> Получить ответ от человека, реально использовавшего инструмент для меня
> предпочтительней.

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

-- 
Led

Re: [devel] I: arepo: next steps

[Vitaly Kuznetsov]

On Wed, 29 Feb 2012 10:31:57 +0200, Michael Shigorin wrote:
> On Wed, Feb 29, 2012 at 10:09:39AM +0400, Vitaly Kuznetsov wrote:
>> Но если ответить на прямой вопрос так сложно,
>> то я не очень понимаю, зачем советовать инструмент.
>
> Посоветовал я и, чгря, не ожидал такого.

Проехали, за совет спасибо, он действительно ценный. Буду пробовать.

Re: [devel] I: arepo: next steps

[Vitaly Kuznetsov]

On Tue, 28 Feb 2012 18:04:01 +0400, Dmitry V. Levin wrote:
> ...

Я тут немножко поигрался в написание arepo-плагина для rpmrepackage. Из 
обнаруженного:
1) Оставлять надо не только set-зависимости, все soname-зависиимости 
могут быть полезны.
2) Скрипты в исходном пакете следует оставлять только для prog-mode. В 
lib-mode они могут не отработать ввиду отсутствия файлов.
3) Мне не очевидно, что делать с Conflicts/Obsoletes. В частности, если 
такой пакет присутствует в новом состоянии репозитория, то, вероятно, 
следует добавить arepo-префикс. Если же он отсутствует, то тут 
существует три варианта: оставить как есть, добавить arepo-префикс и 
удвоить (с arepo-префиксом и без). Я пока склоняюсь к последнему 
варианту для prog-mode и ко второму для lib-mode.

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

Re: [devel] I: arepo: next steps

[Vitaly Kuznetsov]

On Thu, 01 Mar 2012 16:09:17 +0400, Vitaly Kuznetsov wrote:
> On Tue, 28 Feb 2012 18:04:01 +0400, Dmitry V. Levin wrote:
>> ...
>
> Я тут немножко поигрался в написание arepo-плагина для rpmrepackage.

rpmrebuild конечно же.

Re: [devel] I: arepo: next steps

[Dmitry V. Levin]

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

On Wed, Feb 29, 2012 at 01:28:45AM +0200, Led wrote:
> On Wednesday 29 February 2012 01:04:33 Dmitry V. Levin wrote:
> > On Wed, Feb 29, 2012 at 12:34:39AM +0200, Led wrote:
> > > On Wednesday 29 February 2012 00:23:16 Dmitry V. Levin wrote:
> >
> > [...]
> >
> > > > Поскольку rpmrebuild существенным образом использует rpmbuild, я считаю
> > > > этот подход небезопасным.  Используемый в rpmrebuild метод - сдампить
> > > > все необходимое в спек, а потом выполнить rpmbuild - это довольно
> > > > рискованная процедура с точки зрения выполнения произвольного кода.  В
> > > > нынешней реализации не видно попыток с этим бороться путем квотирования
> > > > всего и вся, и я, честно говоря, не уверен, что нам стоит идти этим
> > > > путем.
> > >
> > > Какой "произвольный код" может оказаться в преамбуле и секции %files
> > > спека?
> >
> > Например, любой текстовый тэг может содержать %макрос и вообще
> > произвольный %(код);
> 
> rpmrebuild экранирует все '%' в генерируемом спеке.

Он не экранирует их в секции %files.  Мы обошли это выкидыванием
из рассмотрения файлов, пути которых содержат такие символы.


-- 
ldv

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