[devel] rpm macros

[devel] rpm macros

[Alexey Tourbin]

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

Вопрос по brainfuck^W rpm macros.

Я хочу один раз подменить __find_requires и __find_provides, отдав в
качестве аргумента новому значению текущее значение:

%fpc_global()	%{?!fpc_%1:%{expand:%%global %1 %2 %%%1%%global fpc_%1 %2}}
%fpc_macro	%([ -x %_rpmlibdir/fpc2.req ])%{fpc_global __find_requires %_rpmlibdir/fpc2.req}%{fpc_global __find_provides %_rpmlibdir/fpc2.prov}
%fpc_dir	%fpc_macro%_libdir/fpc2
%fpc_make	make RELEASE=1 CREATESMART=1 LINKSMART=1 FPCDIR=%fpc_dir

К сожалению аргументы накапливаются в цикле:

$ rpm --eval $'%fpc_dir\n%fpc_make\n%__find_requires'           
/usr/lib/fpc2
make RELEASE=1 CREATESMART=1 LINKSMART=1 FPCDIR=/usr/lib/fpc2
/usr/lib/rpm/fpc2.req /usr/lib/rpm/fpc2.req /usr/lib/rpm/find-requires
$

Что я делаю не так?  Как сделать правильно?

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

Re: [devel] rpm macros

[Alexey Tourbin]

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

On Sun, Sep 10, 2006 at 10:59:13PM +0400, Alexey Tourbin wrote:
> Вопрос по brainfuck^W rpm macros.
> 
> Я хочу один раз подменить __find_requires и __find_provides, отдав в
> качестве аргумента новому значению текущее значение:
> 
> %fpc_global()	%{?!fpc_%1:%{expand:%%global %1 %2 %%%1%%global fpc_%1 %2}}

%fpc_global()	%{expand:%%{?!fpc_%1:%%global %1 %2 %%%1%%global fpc_%1 %2}}

Так работает.  По-видимому имя переменной в ?! не может содержать ещё
одну меременную, примерно как в шелле.  Значт, нужен ещё один eval.

> %fpc_macro	%([ -x %_rpmlibdir/fpc2.req ])%{fpc_global __find_requires %_rpmlibdir/fpc2.req}%{fpc_global __find_provides %_rpmlibdir/fpc2.prov}
> %fpc_dir	%fpc_macro%_libdir/fpc2
> %fpc_make	make RELEASE=1 CREATESMART=1 LINKSMART=1 FPCDIR=%fpc_dir
> 
> К сожалению аргументы накапливаются в цикле:
> 
> $ rpm --eval $'%fpc_dir\n%fpc_make\n%__find_requires'           
> /usr/lib/fpc2
> make RELEASE=1 CREATESMART=1 LINKSMART=1 FPCDIR=/usr/lib/fpc2
> /usr/lib/rpm/fpc2.req /usr/lib/rpm/fpc2.req /usr/lib/rpm/find-requires
> $

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

[devel] spt/spt3

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

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

Есть ценное предложение spt-строителям.

spt штука большая, и не всем может подходить для своих целей. Но у всех
дистрибутивостроительных велосипедов, работающих поверх hasher'а есть море
общего кода.

Предлагаю этот код вынести в отдельные маленькие утилиты, которые бы
использовались spt, spt3 и самодельными велосипедами.

Собственно если кто-то из работающих над spt/spt3 согласиться потратить
свое время на то чтобы посмотреть что у меня получиться, и попинать -- я
это сделаю.

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

http://freesource.info
----------------------------------------------------------------------------
Чтобы "заткнуть дыру", я "пошел на сделку с совестью" и отключил тесты.
		-- at in devel@

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

Re: [devel] spt/spt3

[Dmitry V. Levin]

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

On Mon, Nov 06, 2006 at 12:21:20AM +0300, Денис Смирнов wrote:
> Есть ценное предложение spt-строителям.
> 
> spt штука большая, и не всем может подходить для своих целей. Но у всех
> дистрибутивостроительных велосипедов, работающих поверх hasher'а есть море
> общего кода.
> 
> Предлагаю этот код вынести в отдельные маленькие утилиты, которые бы
> использовались spt, spt3 и самодельными велосипедами.
> 
> Собственно если кто-то из работающих над spt/spt3 согласиться потратить
> свое время на то чтобы посмотреть что у меня получиться, и попинать -- я
> это сделаю.

Как-то раз я был свидетелем того, как все известные мне действующие
spt-строители (~4 чел.) собрались в одной комнате, чтобы обсудить будущее spt.
Оказалось, что приоритеты развития spt у них отличаются, и у меня не сложилось
ощущение того, что они договорились по принципиальным вопросам.

Может быть они сами выскажутся...


-- 
ldv

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

Re: [devel] spt/spt3

[Hihin Ruslan]

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

Здравствуйте Dmitry V. Levin
  В сообщении от Monday 06 November 2006 00:36 Dmitry V. Levin 
написал(a):
 > On Mon, Nov 06, 2006 at 12:21:20AM +0300, Денис Смирнов wrote:
 > > Есть ценное предложение spt-строителям.
 > >
 > >
 > >
 > > spt штука большая, и не всем может подходить для своих целей. Но у
 > > всех
 > >
 > > дистрибутивостроительных велосипедов, работающих поверх hasher'а
 > > есть море
 > >
 > > общего кода.
 > >
 > >
 > >
 > > Предлагаю этот код вынести в отдельные маленькие утилиты, которые
 > > бы
 > >
 > > использовались spt, spt3 и самодельными велосипедами.
 > >
 > >
 > >
 > > Собственно если кто-то из работающих над spt/spt3 согласиться
 > > потратить
 > >
 > > свое время на то чтобы посмотреть что у меня получиться, и
 > > попинать -- я
 > >
 > > это сделаю.
 >
 > Как-то раз я был свидетелем того, как все известные мне действующие
 >
 > spt-строители (~4 чел.) собрались в одной комнате, чтобы обсудить
 > будущее spt.
 >
 > Оказалось, что приоритеты развития spt у них отличаются, и у меня не
 > сложилось
 >
 > ощущение того, что они договорились по принципиальным вопросам.
 >
 >
 >
 > Может быть они сами выскажутся...
Ну, я себя, к сожалению не отношу к spt строителям, скорее к 
изобретателям велосипедов на их основе.

Надо, как минимум, договорится о том, что-бы все profile имели общцю 
структуру, что-бы была совместимость по созданным profile, например 
между separator. spt и spt3 (а так для каждого надо создавать свой 
profile). 
 
-- 
С уважением Xихин Руслан

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

Re: [devel] spt/spt3

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

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

On Mon, Nov 06, 2006 at 12:36:03AM +0300, Dmitry V. Levin wrote:

DVL> Как-то раз я был свидетелем того, как все известные мне действующие
DVL> spt-строители (~4 чел.) собрались в одной комнате, чтобы обсудить будущее spt.
DVL> Оказалось, что приоритеты развития spt у них отличаются, и у меня не сложилось
DVL> ощущение того, что они договорились по принципиальным вопросам.
DVL> Может быть они сами выскажутся...

Подобные системы состоят как минимум из двух уровней. Нижний напрямую
взаимодействует с hasher chroot, и занимается его формированием,
модификацией, запуском внутри него скриптов, а также экспортом в различных
форматах (от tar/cpio до образов файловых систем) и формированием
репозиториев из списков пакетов. Эта часть может быть общей.

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

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

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

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

http://freesource.info
----------------------------------------------------------------------------
> в пакете отсутствует man для subst.
Может лучше плавно переходить на "sed -i"?
		-- ldv in #6571


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

Re: [devel] spt/spt3

[Konstantin A. Lepikhov]

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

Hi Денис!

Monday 06, at 07:03:30 PM you wrote:

> On Mon, Nov 06, 2006 at 12:36:03AM +0300, Dmitry V. Levin wrote:
> 
> DVL> Как-то раз я был свидетелем того, как все известные мне действующие
> DVL> spt-строители (~4 чел.) собрались в одной комнате, чтобы обсудить будущее spt.
> DVL> Оказалось, что приоритеты развития spt у них отличаются, и у меня не сложилось
> DVL> ощущение того, что они договорились по принципиальным вопросам.
> DVL> Может быть они сами выскажутся...
> 
> Подобные системы состоят как минимум из двух уровней. Нижний напрямую
> взаимодействует с hasher chroot, и занимается его формированием,
> модификацией, запуском внутри него скриптов, а также экспортом в различных
> форматах (от tar/cpio до образов файловых систем) и формированием
> репозиториев из списков пакетов. Эта часть может быть общей.
собственно, так и сделано в spt. В spt3 предлагается система вложенных
chroot'ов (один инструментальный, другой для создания выходного image).
Т.е. уже на данной стадии начинаются разногласия. Мне мой подход нравится,
поскольку позволяет сразу получать tar.gz/tar.bz2 на выходе без создания
промежуточного chroot'а.

...
> Так что я считаю нормальным что spt-подобных у нас будет целая стая первое
> время. Но я считаю совершенно ненормальным во-первых то, что в них есть
> масса дублирующегося кода (который необходим в каждом spt подобном
> творении), а также то, что сейчас spt и spt3 конфликтуют по файлам. Если
> авторы не могут найти общий язык, значит это разные продукты, которые
> должны при желании пользователя устанавливаться параллельно.
spt3 - это распиленный на части spt старой редакции, который deprecated и
используется по-причине "патамушта работает в vserver" (предыдущаяя
отмазка с installer и кросс-сборки на x86_64 на сегодняшний день
неактуальна). Почему он работает в vserver, а мой spt нет, не знает даже
greycat@ ;) Т.е. я за развитие spt3, но только на базе _текущего кода_
spt, иначе он будет тащить за собой все родовые травмы separator'а и
ранних версий spt.

-- 
WBR et al.

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

Re: [devel] spt/spt3

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

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

On Tue, Nov 07, 2006 at 11:14:38AM +0300, Konstantin A. Lepikhov wrote:

>> Подобные системы состоят как минимум из двух уровней. Нижний напрямую
>> взаимодействует с hasher chroot, и занимается его формированием,
>> модификацией, запуском внутри него скриптов, а также экспортом в различных
>> форматах (от tar/cpio до образов файловых систем) и формированием
>> репозиториев из списков пакетов. Эта часть может быть общей.
KAL> собственно, так и сделано в spt. В spt3 предлагается система вложенных
KAL> chroot'ов (один инструментальный, другой для создания выходного image).
KAL> Т.е. уже на данной стадии начинаются разногласия. Мне мой подход нравится,
KAL> поскольку позволяет сразу получать tar.gz/tar.bz2 на выходе без создания
KAL> промежуточного chroot'а.

А с чем необходимость такого извращения?

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

http://freesource.info
----------------------------------------------------------------------------
P.S. Вообще-то это offtopic для данной баги. :)
		-- ldv in #7606

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

Re: [devel] spt/spt3

[Konstantin A. Lepikhov]

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

Hi Денис!

Tuesday 07, at 11:33:19 AM you wrote:

> On Tue, Nov 07, 2006 at 11:14:38AM +0300, Konstantin A. Lepikhov wrote:
> 
> >> Подобные системы состоят как минимум из двух уровней. Нижний напрямую
> >> взаимодействует с hasher chroot, и занимается его формированием,
> >> модификацией, запуском внутри него скриптов, а также экспортом в различных
> >> форматах (от tar/cpio до образов файловых систем) и формированием
> >> репозиториев из списков пакетов. Эта часть может быть общей.
> KAL> собственно, так и сделано в spt. В spt3 предлагается система вложенных
> KAL> chroot'ов (один инструментальный, другой для создания выходного image).
> KAL> Т.е. уже на данной стадии начинаются разногласия. Мне мой подход нравится,
> KAL> поскольку позволяет сразу получать tar.gz/tar.bz2 на выходе без создания
> KAL> промежуточного chroot'а.
> 
> А с чем необходимость такого извращения?
Какого? С кучей chroot'ов? Было пространное обсуждение, что это поможет
в случае cross- сборок под другие архитектуры. 

-- 
WBR et al.

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

Re: [devel] double chroot

[Alex V. Myltsev]

On Tue, 7 Nov 2006 11:36:53 +0300
Konstantin A. Lepikhov wrote:
> > KAL> собственно, так и сделано в spt. В spt3 предлагается система
> > KAL> вложенных chroot'ов (один инструментальный, другой для
> > KAL> создания выходного image).
> > А с чем необходимость такого извращения?
> Какого? С кучей chroot'ов? Было пространное обсуждение, что это
> поможет в случае cross- сборок под другие архитектуры. 
То пространное обсуждение, кстати, закончилось на том, что не поможет.
Скрипты пакетов всё равно надо выполнять внутри data-чрута, 

Изначально у меня два чрута появились из такого противоречия:

* инструменты (mksquashfs, genromfs, mkisofs и прочие необходимые
  для сборки вещи) нельзя выполнять в чруте, потому что мы их туда не
  устанавливаем (они не нужны на получающемся образе, их может не
  быть в исходном репозитарии).
* инструменты нельзя выполнять в хост-системе, потому что тогда
  потеряется информация, которую хранит fakeroot.

Значит, нужно сделать промежуточный chroot и устанавливать инструменты
в него.

(Да, у меня тоже есть полусепаратор, называется SProuT, лежит
здесь: git.alt:/people/avm/packages/sprout.git. Оно делает два хашера
друг над другом, см. sprout-init, sprout-run, sprout-install.)

Re: [devel] spt/spt3

[Mikhail Yakshin]

Konstantin A. Lepikhov пишет:
>> Подобные системы состоят как минимум из двух уровней. Нижний напрямую
>> взаимодействует с hasher chroot, и занимается его формированием,
>> модификацией, запуском внутри него скриптов, а также экспортом в различных
>> форматах (от tar/cpio до образов файловых систем) и формированием
>> репозиториев из списков пакетов. Эта часть может быть общей.
> собственно, так и сделано в spt. В spt3 предлагается система вложенных
> chroot'ов (один инструментальный, другой для создания выходного image).
> Т.е. уже на данной стадии начинаются разногласия. Мне мой подход нравится,
> поскольку позволяет сразу получать tar.gz/tar.bz2 на выходе без создания
> промежуточного chroot'а.

Можно тебя попросить как-то прокомментировать твою реализацию? Просто ты 
сделал ее довольно быстро с лаконичным:

 > - раздельная сборка chroot и образа (т.е. придуман альтернативный
 > вариант не использующий раздельные chroot'ы);

Я сейчас изучаю текущую версию spt и попробую это все максимально смерджить.

> spt3 - это распиленный на части spt старой редакции, который deprecated и
> используется по-причине "патамушта работает в vserver" (предыдущаяя
> отмазка с installer и кросс-сборки на x86_64 на сегодняшний день
> неактуальна). Почему он работает в vserver, а мой spt нет, не знает даже
> greycat@ ;)  Т.е. я за развитие spt3, но только на базе _текущего кода_
> spt, иначе он будет тащить за собой все родовые травмы separator'а и
> ранних версий spt.

Замечательно. Кость, ну чего ругаться-то? Откуда ты придумал, что я 
вдруг встал против всех и принципиально препятствую каким-то инновациям?

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

-- 
WBR, GreyCat

Re: [devel] spt/spt3

[Konstantin A. Lepikhov]

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

Hi Mikhail!

Tuesday 07, at 01:17:13 PM you wrote:

<skip>
> Можно тебя попросить как-то прокомментировать твою реализацию? Просто ты 
> сделал ее довольно быстро с лаконичным:
> 
>  > - раздельная сборка chroot и образа (т.е. придуман альтернативный
>  > вариант не использующий раздельные chroot'ы);
> 
> Я сейчас изучаю текущую версию spt и попробую это все максимально смерджить.
там все просто - делается первый chroot с пакетами, потом для него
выполняются все post/postlocal скрипты, затем полученный chroot
заворачивается в .tar архив и кладется в сторонку. Затем делается второй
chroot, куда ставятся инструменты, .tar разворачивается в /tmp/.archive, и
запускается создание image для данного /tmp/.archive. В случае создания
tar.bz2/tar.gz, стадия со вторым chroot'ом пропускается и просто сжимается
.tar, полученный на первой стадии.

> 
> > spt3 - это распиленный на части spt старой редакции, который deprecated и
> > используется по-причине "патамушта работает в vserver" (предыдущаяя
> > отмазка с installer и кросс-сборки на x86_64 на сегодняшний день
> > неактуальна). Почему он работает в vserver, а мой spt нет, не знает даже
> > greycat@ ;)  Т.е. я за развитие spt3, но только на базе _текущего кода_
> > spt, иначе он будет тащить за собой все родовые травмы separator'а и
> > ранних версий spt.
> 
> Замечательно. Кость, ну чего ругаться-то? Откуда ты придумал, что я 
> вдруг встал против всех и принципиально препятствую каким-то инновациям?
нет, мне не нравится, когда мне говорят, что spt не подоходит _вообще_
"патамушта не работает в vserver", или когда решение для тестирование
installer'а выбирается кулуарно с такими вот объяснениями. Я ничему не
препятствую, просто иду рядом :)

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

-- 
WBR et al.

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

Re: [devel] spt/spt3

[Mikhail Yakshin]

Konstantin A. Lepikhov пишет:
> Hi Mikhail!
> 
> Tuesday 07, at 01:17:13 PM you wrote:
> 
> <skip>
>> Можно тебя попросить как-то прокомментировать твою реализацию? Просто ты 
>> сделал ее довольно быстро с лаконичным:
>>
>>  > - раздельная сборка chroot и образа (т.е. придуман альтернативный
>>  > вариант не использующий раздельные chroot'ы);
>>
>> Я сейчас изучаю текущую версию spt и попробую это все максимально смерджить.
> там все просто - делается первый chroot с пакетами, потом для него
> выполняются все post/postlocal скрипты, затем полученный chroot
> заворачивается в .tar архив и кладется в сторонку.  Затем делается второй
> chroot, куда ставятся инструменты, .tar разворачивается в /tmp/.archive, и
> запускается создание image для данного /tmp/.archive.

Имеется в виду $chroot/tmp/.archive, видимо, в уже новом чруте?

> В случае создания
> tar.bz2/tar.gz, стадия со вторым chroot'ом пропускается и просто сжимается
> .tar, полученный на первой стадии.

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

По сути - $chroot/ и $chroot/tmp/.archive - это и есть эти двойные 
чруты, только ты их предлагаешь создавать не сразу, а по мере 
необходимости на более поздних стадиях.

Минусов я пока вижу 2:

1) мне не очень нравится перспектива - "завернем все в tar", а потом 
"развернем его же в /tmp/.archive", т.е. фактически - переместим каталог 
- но в принципе это как раз можно изменить на просто перемещение?

2) в первом, настоящем, chroot'е должен быть tar, который "сам себя 
завернет".

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

>>> spt3 - это распиленный на части spt старой редакции, который deprecated и
>>> используется по-причине "патамушта работает в vserver" (предыдущаяя
>>> отмазка с installer и кросс-сборки на x86_64 на сегодняшний день
>>> неактуальна). Почему он работает в vserver, а мой spt нет, не знает даже
>>> greycat@ ;)  Т.е. я за развитие spt3, но только на базе _текущего кода_
>>> spt, иначе он будет тащить за собой все родовые травмы separator'а и
>>> ранних версий spt.
>> Замечательно. Кость, ну чего ругаться-то? Откуда ты придумал, что я 
>> вдруг встал против всех и принципиально препятствую каким-то инновациям?
> нет, мне не нравится, когда мне говорят, что spt не подоходит _вообще_
> "патамушта не работает в vserver", или когда решение для тестирование
> installer'а выбирается кулуарно с такими вот объяснениями. Я ничему не
> препятствую, просто иду рядом :)

Ну давай найдем человека, который так говорит и побьем его? %)

Я постараюсь смерджить по возможности все, что получится и выложить для 
просмотра новый релиз spt3 в ближайшее время.

-- 
WBR, GreyCat

Re: [devel] spt/spt3

[Konstantin A. Lepikhov]

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

Hi Mikhail!

Tuesday 07, at 02:29:23 PM you wrote:

<skip>
> Имеется в виду $chroot/tmp/.archive, видимо, в уже новом чруте?
да.

..
> По сути - $chroot/ и $chroot/tmp/.archive - это и есть эти двойные 
> чруты, только ты их предлагаешь создавать не сразу, а по мере 
> необходимости на более поздних стадиях.
> 
> Минусов я пока вижу 2:
> 
> 1) мне не очень нравится перспектива - "завернем все в tar", а потом 
> "развернем его же в /tmp/.archive", т.е. фактически - переместим каталог 
> - но в принципе это как раз можно изменить на просто перемещение?
можно, но что делать с правами на файлы.

> 
> 2) в первом, настоящем, chroot'е должен быть tar, который "сам себя 
> завернет".
да, но это не сильный overhead ;)

..
> Ну давай найдем человека, который так говорит и побьем его? %)
а чего его искать, тут он, даже на devel@ пописан :)

> 
> Я постараюсь смерджить по возможности все, что получится и выложить для 
> просмотра новый релиз spt3 в ближайшее время.
отлично!

-- 
WBR et al.

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

Re: [devel] spt/spt3

[Sergey Vlasov]

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

On Tue, Nov 07, 2006 at 02:29:23PM +0300, Mikhail Yakshin wrote:
> 2) в первом, настоящем, chroot'е должен быть tar, который "сам себя 
> завернет".

Если заменить их на find-static + cpio-static, которыми пользуется сам
hasher, можно избавиться даже от этого ограничения.

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

Re: [devel] spt/spt3

[Konstantin A. Lepikhov]

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

Hi Sergey!

Tuesday 07, at 03:41:52 PM you wrote:

> On Tue, Nov 07, 2006 at 02:29:23PM +0300, Mikhail Yakshin wrote:
> > 2) в первом, настоящем, chroot'е должен быть tar, который "сам себя 
> > завернет".
> 
> Если заменить их на find-static + cpio-static, которыми пользуется сам
> hasher, можно избавиться даже от этого ограничения.
тогда для tgz/tbz2 придется ставить tar и разворачивать cpio еще раз.

-- 
WBR et al.

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

Re: [devel] spt/spt3

[Dmitry V. Levin]

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

On Tue, Nov 07, 2006 at 04:01:26PM +0300, Konstantin A. Lepikhov wrote:
> Tuesday 07, at 03:41:52 PM you wrote:
> > On Tue, Nov 07, 2006 at 02:29:23PM +0300, Mikhail Yakshin wrote:
> > > 2) в первом, настоящем, chroot'е должен быть tar, который "сам себя 
> > > завернет".
> > 
> > Если заменить их на find-static + cpio-static, которыми пользуется сам
> > hasher, можно избавиться даже от этого ограничения.
> тогда для tgz/tbz2 придется ставить tar и разворачивать cpio еще раз.

Кстати, а не добавить ли в vzctl поддержку более широкого спектра типов
архивов?


-- 
ldv

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

Re: [devel] vzctl

[Slava Dubrovskiy]

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

Dmitry V. Levin пишет:
>> тогда для tgz/tbz2 придется ставить tar и разворачивать cpio еще раз.
>>     
> Кстати, а не добавить ли в vzctl поддержку более широкого спектра типов
> архивов?
>   
Лучше нормальную поддержку veth сделать.
А то до сих пор не ясно как настраивать veth (назначать IP, включать в
бридж и т.д.) на HN после того как его поднял vznetcfg.
Щас все ручками...

-- 
С уважением,
Дубровский Вячеслав.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3237 bytes --]

Re: [devel] vzctl

[Dmitry V. Levin]

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

On Tue, Nov 07, 2006 at 03:40:21PM +0200, Slava Dubrovskiy wrote:
> Dmitry V. Levin пишет:
> >> тогда для tgz/tbz2 придется ставить tar и разворачивать cpio еще раз.
> >>     
> > Кстати, а не добавить ли в vzctl поддержку более широкого спектра типов
> > архивов?
> >   
> Лучше нормальную поддержку veth сделать.

Это ортогональные задачи.


-- 
ldv

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

Re: [devel] double chroot

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

[-- Attachment #1.1: Type: text/plain, Size: 831 bytes --]

On Tue, Nov 07, 2006 at 12:25:36PM +0300, Alex V. Myltsev wrote:

AVM> * инструменты (mksquashfs, genromfs, mkisofs и прочие необходимые
AVM>   для сборки вещи) нельзя выполнять в чруте, потому что мы их туда не
AVM>   устанавливаем (они не нужны на получающемся образе, их может не
AVM>   быть в исходном репозитарии).
AVM> * инструменты нельзя выполнять в хост-системе, потому что тогда
AVM>   потеряется информация, которую хранит fakeroot.

Какой кошмар. Пример скрипта который без этого всего обходится в аттаче.
Все что требуется -- _библиотеки_, которые требует этот пакет (в
большинстве случаев речь всего лишь о glibc).

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

http://freesource.info
----------------------------------------------------------------------------
Настоящие программисты делают так: COPY CON PROGRAM. EXE.

[-- Attachment #1.2: aptbox2cpio --]
[-- Type: text/plain, Size: 1264 bytes --]

#!/bin/bash
#=============================================================================#
#                  Make cpios image from fakeroot directory                   #
#=============================================================================#
# Requires:
#	hasher by Dmitry V. Levin (ldv)
#   	cpio
#=============================================================================#
# (C) Denis Smirnov <mithraen@freesource.info                     12.06.2006  #
#=============================================================================#
set +e

WORKDIR=`realpath $1`
touch "$2"
RESULT=`realpath $2`
chroot="$WORKDIR/chroot/"

T=`mktemp`
echo -en '/etc\0/etc/group\0/etc/passwd\0' > $T

cp -a `which cpio` $chroot/.host/

echo "Creating $RESULT" | csed '/.*/ p green' >&2
hsh-run "$WORKDIR" --rooter --save-fakeroot -- /.host/find / \
	-mindepth 1 \
	-name .in -prune -o \
	-name .out -prune -o \
	-name .host -prune -o \
	-name .fakedata -prune -o \
	-name .altlinux.img -prune -o \
	-wholename /usr/lib*/*fakeroot* -prune -o \
	-print0 \
	| grep -vz ^/etc$ \
	| grep -vz ^/etc/passwd$ \
	| grep -vz ^/etc/group$ \
	>> $T \
	2> /dev/null

hsh-run "$WORKDIR"  --rooter --save-fakeroot -- /.host/cpio \
	-0 -c --create --quiet > "$RESULT" < $T

rm -f $T


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

Re: [devel] spt/spt3

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

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

On Tue, Nov 07, 2006 at 02:29:23PM +0300, Mikhail Yakshin wrote:

MY> Я постараюсь смерджить по возможности все, что получится и выложить для 
MY> просмотра новый релиз spt3 в ближайшее время.

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

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

http://freesource.info
----------------------------------------------------------------------------
Это политический вопрос, я бы не хотел в него ввязываться.
		-- ldv in #7755

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

Re: [devel] [JT] double chroot

[Alex V. Myltsev]

On Tue, 7 Nov 2006 23:31:43 +0300
Денис Смирнов wrote:
> Какой кошмар. Пример скрипта который без этого всего обходится в
> аттаче. Все что требуется -- _библиотеки_, которые требует этот пакет
Да не такой уж и кошмар, по-моему. 
Нравится вам руками бинарники и библиотеки перекладывать --
перекладывайте руками. Мне больше нравится их устанавливать package
manager'ом, в данном случае -- RPM. Дело вкуса.

Re: [devel] spt/spt3

[Dmitry V. Levin]

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

On Tue, Nov 07, 2006 at 11:34:00PM +0300, Денис Смирнов wrote:
> On Tue, Nov 07, 2006 at 02:29:23PM +0300, Mikhail Yakshin wrote:
> 
> MY> Я постараюсь смерджить по возможности все, что получится и выложить для 
> MY> просмотра новый релиз spt3 в ближайшее время.
> 
> А я предлагаю прекратить порочную практику мержить все подряд, и общий код
> выделять в отдельный пакет.

Я верю, что Михаил ничего не испортит, а наоборот, сделает всем лучше. :)


-- 
ldv

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

Re: [devel] spt/spt3

[Dmitry V. Levin]

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

On Tue, Nov 07, 2006 at 02:29:23PM +0300, Mikhail Yakshin wrote:
[...]
> Ну, на самом деле, из того, что я вижу в том spt, который сейчас в 
> Сизифе и из того, что ты сказал - принципиальных различий у этого 
> подхода и "двойных чрутов" - нет.
> 
> По сути - $chroot/ и $chroot/tmp/.archive - это и есть эти двойные 
> чруты, только ты их предлагаешь создавать не сразу, а по мере 
> необходимости на более поздних стадиях.
> 
> Минусов я пока вижу 2:
> 
> 1) мне не очень нравится перспектива - "завернем все в tar", а потом 
> "развернем его же в /tmp/.archive", т.е. фактически - переместим каталог 
> - но в принципе это как раз можно изменить на просто перемещение?

Если вопрос в оптимальности, то можно замерить производительность каждого
из этиъ двух вариантов.

> 2) в первом, настоящем, chroot'е должен быть tar, который "сам себя 
> завернет".

Вместо tar'а можно использовать $chroot/.host/{find,cpio}, тем более что
cpio должен уметь --format=ustar.

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

Давайте тщательно взвесим все за и против, чтобы вопросов не осталось.


-- 
ldv

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

Re: [devel] [JT] double chroot

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

On Wed, Nov 08, 2006 at 12:32:09AM +0300, Alex V. Myltsev wrote:

>> Какой кошмар. Пример скрипта который без этого всего обходится в
>> аттаче. Все что требуется -- _библиотеки_, которые требует этот пакет
AVM> Да не такой уж и кошмар, по-моему. 
AVM> Нравится вам руками бинарники и библиотеки перекладывать --
AVM> перекладывайте руками. Мне больше нравится их устанавливать package
AVM> manager'ом, в данном случае -- RPM. Дело вкуса.

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

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

http://freesource.info
----------------------------------------------------------------------------
Я человек добрый, мне всё равно кого пытать, лишь бы всё работало :)
		-- mithraen in talk-room@

Re: [devel] [JT] double chroot

[Alex V. Myltsev]

On Wed, 8 Nov 2006 02:24:44 +0300
Денис Смирнов wrote:
> Создавать отдельный чрут только чтобы установить бинарник?
> Это может иметь [смысл] исключительно для кросс-сборки.
Ну можно написать большую проверку:

  если(это_кросс_сборка ||
       glibc_в_системе_новее_чем_в_чруте ||
       установлена_не_та_версия_mksquashfs || ...)
  то сделать_второй_чрут;
  иначе скопировать_бинарники;

Я написал проще:

  сделать_второй_чрут;

Чем плохо?

Re: [devel] spt/spt3

[Hihin Ruslan]

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

Здравствуйте все :)

Попробовал объединить оба пакета spt и spt3 в один пакет mspt (много 
spt :) ).
Залил в Дедалус. Основная мысль на сегодня - объединить функции в 
отдельный пакет. Профили в другой пакет. Сами spt и spt3 - в свои 
пакеты.

Дальнейшая мысль моя движется в направлени:
 - иметь набор пополняемых фунций и макросов; 
 - иметь "движок", который эти функции выполняет;
 - иметь стандартный файл - типа *.spec из rpm, из которого  (в 
соответствии с котором) движок  вызывает стандартные функции для 
построения образа.
- профайлы можно по аналогии с rpm считать source. :) 
- завести для построения образа стандартные пути (опять по-аналогии с 
построением rpm).

Т.е. иметь "стандартный путь построения" в котором указываются Source 
(профайл) и метод построения (spt или spt3). Плюс появляется 
возможность добавления в спеке добавочных функций и порядок действий 
для построения необходимого образа.

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

Насчёт движка - пока не знаю как его и на чём собрать :(, но такая мысль 
такая меня не покидает :) 

PS Пока попробую заняться добавлением добавить  манов по spt и spt3
-- 
С уважением Xихин Руслан

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

Re: [devel] spt/spt3

[Mikhail Yakshin]

Приветствую!

> Попробовал объединить оба пакета spt и spt3 в один пакет mspt (много 
> spt :) ).
> Залил в Дедалус. Основная мысль на сегодня - объединить функции в 
> отдельный пакет. Профили в другой пакет. Сами spt и spt3 - в свои 
> пакеты.

Не очень понятно, зачем это было сделать. Я посмотрел пакет - там
действительно просто взяты 2 тарболла от spt3 и spt и упакованы. Что в
итоге достигнуто?

"Функций" там аж на целых 5 или 6 функций общих, полтора килобайта.
Метаданные по 1 установленному RPM-пакету, насколько я помню, занимают
на порядок больше. Профили spt и spt3 имеют радикально разную структуру,
объединить их просто так не получится - а самое главное, не очень
понятно, зачем это делать.

Думаю, lakostis@ тоже выскажется, и тоже скорее всего в плане
непонимания, зачем делать именно так %)

> Дальнейшая мысль моя движется в направлени:
>  - иметь набор пополняемых фунций и макросов;

/usr/bin/spt-* в spt3; думаю, скоро они переедут в /usr/share/spt3/tasks

>  - иметь "движок", который эти функции выполняет;

/usr/bin/spt3 в spt3 (в старом spt3, который сейчас в Сизифе - это
просто /usr/bin/spt)

>  - иметь стандартный файл - типа *.spec из rpm, из которого  (в 
> соответствии с котором) движок  вызывает стандартные функции для 
> построения образа.

$PROFILE_DIR/recipe

> - профайлы можно по аналогии с rpm считать source. :) 
> - завести для построения образа стандартные пути (опять по-аналогии с 
> построением rpm).

Заведены и описаны в документации.

> Т.е. иметь "стандартный путь построения" в котором указываются Source 
> (профайл) и метод построения (spt или spt3). Плюс появляется 
> возможность добавления в спеке добавочных функций и порядок действий 
> для построения необходимого образа.
> 
> Таким образом должна получиться достаточно гибкая система.  
> 
> Насчёт движка - пока не знаю как его и на чём собрать :(, но такая мысль 
> такая меня не покидает :) 

Руслан, я очень рад, что тема spt и сборок образов вызывает такой
резонанс и желание что-то делать, но давайте сначала все-таки посмотрим,
что уже сделано?

> PS Пока попробую заняться добавлением добавить  манов по spt и spt3

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

-- 
WBR, Mikhail Yakshin
ALT Linux [http://www.altlinux.ru] [xmpp:greycat@altlinux.org]

Re: [devel] spt/spt3

[Hihin Ruslan]

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

Здравствуйте Mikhail Yakshin
  В сообщении от Sunday 10 December 2006 03:54 Mikhail Yakshin 
написал(a):
 > Приветствую!
 > > Попробовал объединить оба пакета spt и spt3 в один пакет mspt
 > > (много
 > > spt :) ).
 > > Залил в Дедалус. Основная мысль на сегодня - объединить функции в
 > > отдельный пакет. Профили в другой пакет. Сами spt и spt3 - в свои
 > > пакеты.
 >
 > Не очень понятно, зачем это было сделать. Я посмотрел пакет - там
 > действительно просто взяты 2 тарболла от spt3 и spt и упакованы. Что
 > в   итоге достигнуто?
Ну для начала достигнуто то, что эти пакеты между собой не конфликтуют, 
ну лично для меня это достаточный плюс - всегда есть желание иметь оба 
инструмента на одной машине :) 

 > "Функций" там аж на целых 5 или 6 функций общих, полтора килобайта.
 > Метаданные по 1 установленному RPM-пакету, насколько я помню,
 > занимают
 > на порядок больше. Профили spt и spt3 имеют радикально разную
 > структуру,
 > объединить их просто так не получится - а самое главное, не очень
 > понятно, зачем это делать.
- Это и хорошо, что есть общие функции - было-бы лучше, что-бы их было 
ещё больше. :). Вообще хотелось-бы сделать набор общих функций, что-бы 
каждому в отдельности не повторять их :). Ну, объём тут имеет малое 
значение - всё равно для создание образа объём нужен на порядок больше.


 > Думаю, lakostis@ тоже выскажется, и тоже скорее всего в плане
 > непонимания, зачем делать именно так %)
Ну, потому и Дедал, что это просто попытка найти общие и выделить 
частное.  Тем-более, что теперь друг-другу не мешают :)
 
И опять-же есть реальная возможность сравнить. Это как-бы первый шажок к 
интеграции этих пакетов. Просто хотелось-бы, что-бы устоявшееся общее 
легло в общее русло и имело свой пакет , а специфика легла в отдельные 
пакеты.

 Если-бы ещё профайлы (их структура) были одинаковы, было-бы ещё лучше. 

 Это даёт возможность написание своего  spec-файла (своего скрипта) 
который может вызывать как фукции spt, так и  spt3 при необходимости, 
исходя из моих нужд. А может и мои собственные, специфичные (например 
образ не на основе syslinux, а на основе grub2). 

>>  - иметь "движок", который эти функции выполняет;

>/usr/bin/spt3 в spt3 (в старом spt3, который сейчас в Сизифе - это 
> просто /usr/bin/spt) 
Ну дело не в названии :) Я всё об интеграции пакетов :)

 > $PROFILE_DIR/recipe
Это я видел и рад этому :)

 > > - профайлы можно по аналогии с rpm считать source. :)
 > >
 > > - завести для построения образа стандартные пути (опять
 > > по-аналогии с
 > > построением rpm).
 >
 > Заведены и описаны в документации.
Не очень понял, но посмотрю.

 > > Насчёт движка - пока не знаю как его и на чём собрать :(, но такая
 > > мысль
 > > такая меня не покидает :)
 >
 > Руслан, я очень рад, что тема spt и сборок образов вызывает такой
 > резонанс и желание что-то делать, но давайте сначала все-таки
 > посмотрим,
 > что уже сделано?
Это правильно :) 

 > > PS Пока попробую заняться добавлением добавить  манов по spt и
 > > spt3
 >
 > Документация по spt3 есть, написана, на мой взгляд - даже
 > относительно
 > полная. В пакет в следующем релизе будет включена, на wiki лежит уже
 > давно - с момента релиза.
Это хорошо, что на вики, но обычно я занимаюсь с созданием образов на 
работе, а там у меня доступа к интернету нет, а так хочется набрать в 
трудный момент man spt(3), а такого и нет :)
Насчёт включения в пакет - очень хорошо :) 

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

Просто ещё раз повторюсь, что мне нужно :
- возможность при построении образа выполнять те или иные функции spt и 
spt3 (даже вперемежку :) ).
- возможность добавления своих функций и возможность писать свои связки 
(скрипты) между вызовом функций.
- неконфликтность между собой различных пакетов для построения образа.

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

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

-- 
С уважением Xихин Руслан

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

Re: [devel] spt/spt3

[Konstantin A. Lepikhov]

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

Hi Mikhail!

Sunday 10, at 03:54:51 AM you wrote:

> Думаю, lakostis@ тоже выскажется, и тоже скорее всего в плане
> непонимания, зачем делать именно так %)
я лучше подожду, пока в каша в объяснениях не превратится во что-то более
внятное :)

-- 
WBR et al.

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