[sisyphus] I: spt3

[sisyphus] I: spt3

[Mikhail Yakshin]

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

Думаю, стоит анонсировать здесь - в последнее время велось много 
разговоров насчет механизма сборки всяких решений, livecd и 
дистрибутивов - я выложил в incoming некую предварительную, но рабочую 
версию того, что ввиду врожденной и непобедимой скромн^W имеет наглость 
называться spt3.

Мысли по ее развитию обсуждались здесь:
http://wiki.sisyphus.ru/devel/spt

Некое описание вкупе с quickstart и reference manual доступно здесь:
http://wiki.sisyphus.ru/devel/spt3

Внутри пакета есть 2 примера профилей - installer и livecd.

Разработка доступна в git.alt в /people/greycat/packages/spt3.git

Приглашаю всех потенциально заинтересованных высказывать свои мнения.

-- 
WBR, Mikhail Yakshin

Re: [sisyphus] I: spt3

[Mikhail Yakshin]

Mikhail Yakshin пишет:
> Приветствую всех!
> 
> Думаю, стоит анонсировать здесь - в последнее время велось много 
> разговоров насчет механизма сборки всяких решений, livecd и 
> дистрибутивов - я выложил в incoming некую предварительную, но рабочую 
> версию того, что ввиду врожденной и непобедимой скромн^W имеет наглость 
> называться spt3.

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

Есть желание двигаться к одному общему знаменателю?

-- 
WBR, Mikhail Yakshin

Re: [sisyphus] I: spt3

[Michael Shigorin]

On Wed, Oct 25, 2006 at 02:49:40PM +0400, Mikhail Yakshin wrote:
> Есть желание двигаться к одному общему знаменателю?

Есть желание поучаствовать в нём (и никакого -- бегать по вилкам).

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

Re: [sisyphus] I: spt3

[Denis Pynkin]

В сообщении от 25 октября 2006 13:49 Mikhail Yakshin написал(a):

> В процессе вчерашнего общения выяснилось, что у нас уже есть 6 вариантов
> таких систем. Господа, признавайтесь сразу - кто *еще* написал свой
> separator или подобную систему и для каких целей?
;-) допиливал сепаратор для своих нужд
среди прочего - очень не хватало возможности сделать снапшот для 
конкретного "релиза" на базе сизифа. Т.е. скопировать в отдельный каталог все 
RPM (SRPM тоже было бы неплохо) для livecd и install, из которых строится 
текущий релиз, а также текущий профайл. 

spt (+bootloader-utils) немного для корректной инсталляции xen ядер (пока еще 
не допилил до конца)

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

-- 
WBR, d4s

Re: [sisyphus] I: spt3

[Mikhail Yakshin]

Denis Pynkin пишет:
> В сообщении от 25 октября 2006 13:49 Mikhail Yakshin написал(a):
> 
>> В процессе вчерашнего общения выяснилось, что у нас уже есть 6 вариантов
>> таких систем. Господа, признавайтесь сразу - кто *еще* написал свой
>> separator или подобную систему и для каких целей?
> ;-) допиливал сепаратор для своих нужд

7 ;)

> среди прочего - очень не хватало возможности сделать снапшот для 
> конкретного "релиза" на базе сизифа. Т.е. скопировать в отдельный каталог все 
> RPM (SRPM тоже было бы неплохо) для livecd и install, из которых строится 
> текущий релиз, а также текущий профайл. 

Не понял, попробуйте переформулировать? Хочется сделать некий 
репозитарий, в котором бы были только те пакеты, которые хочется? Тогда 
это по сути то, что делает spt-create-repo.

> spt (+bootloader-utils) немного для корректной инсталляции xen ядер (пока еще 
> не допилил до конца)

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

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

-- 
WBR, Mikhail Yakshin

Re: [sisyphus] I: spt3

[Denis Pynkin]

В сообщении от 26 октября 2006 11:31 Mikhail Yakshin написал(a):

> > среди прочего - очень не хватало возможности сделать снапшот для
> > конкретного "релиза" на базе сизифа. Т.е. скопировать в отдельный каталог
> > все RPM (SRPM тоже было бы неплохо) для livecd и install, из которых
> > строится текущий релиз, а также текущий профайл.
> Не понял, попробуйте переформулировать? Хочется сделать некий
> репозитарий, в котором бы были только те пакеты, которые хочется? Тогда
> это по сути то, что делает spt-create-repo.
сразу не обратил внимания.
почти то, что надо, но не хватает еще: 
1. если используется много файлов-списков пакетов, то вызывать придется для 
каждого. Вполне возможно, что и каталогов с такими файлами м.б. несколько - у 
меня так и было. Причем списки частично пересекаются.
2. копирования самого $work_dir/profile - т.к. содержимое тоже может 
изменяться от версии к версии (документация, альтернативные образы для 
загрузки - это то, что у меня было)
3. Над этим не работал, но очень желательно копировать также и SRPM всех 
пакетов.
4. создать sources.list для apt, привязанный только к конкретному релизу.

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

> Посмотрите тогда, пожалуйста, на spt3 и выскажите свои замечания - что
> там сейчас не хватает, что архитектурно не нравится и т.п.
пока что усиленно изучаю http://wiki.sisyphus.ru/devel/git ;-)
Поэтому если что-то из перечисленного уже имеется - прошу простить, т.к. 
основывался только на документации.

-- 
WBR, d4s

Re: [sisyphus] I: spt3

[Mikhail Yakshin]

Denis Pynkin пишет:
> В сообщении от 26 октября 2006 11:31 Mikhail Yakshin написал(a):
> 
>>> среди прочего - очень не хватало возможности сделать снапшот для
>>> конкретного "релиза" на базе сизифа. Т.е. скопировать в отдельный каталог
>>> все RPM (SRPM тоже было бы неплохо) для livecd и install, из которых
>>> строится текущий релиз, а также текущий профайл.
>> Не понял, попробуйте переформулировать? Хочется сделать некий
>> репозитарий, в котором бы были только те пакеты, которые хочется? Тогда
>> это по сути то, что делает spt-create-repo.
> сразу не обратил внимания.
> почти то, что надо, но не хватает еще: 
> 1. если используется много файлов-списков пакетов, то вызывать придется для 
> каждого. Вполне возможно, что и каталогов с такими файлами м.б. несколько - у 
> меня так и было. Причем списки частично пересекаются.
> 2. копирования самого $work_dir/profile - т.к. содержимое тоже может 
> изменяться от версии к версии (документация, альтернативные образы для 
> загрузки - это то, что у меня было)
> 3. Над этим не работал, но очень желательно копировать также и SRPM всех 
> пакетов.
> 4. создать sources.list для apt, привязанный только к конкретному релизу.
> 
> как резюме: общая цель - получить каталог, в котором собрано все 
> вышеперечисленное, после чего иметь возможность натравить на него spt и 
> получить конечный образ диска без использования внешних репозиториев, 
> настроек и т.п.
> SRPMs нужны для того, чтобы обеспечить полноценную поддержку полученного 
> продукта, а не искать потом старые версии исходников по файлопомойкам ;-)

Примерно понятно, насколько я понял - это ведь не какой-то принципиально 
иной шаг сборки требуется - это просто должна быть некая сторонняя 
утилита, которая соберет весь "набор дистрибутивостроителя" для 
дальнейшей консервации. Внутри она может использовать spt-create-repo, а 
может не использовать - т.е. сейчас главное, что ее ничто не будет 
препятствовать написать потом.

-- 
WBR, Mikhail Yakshin

Re: [sisyphus] I: spt3

[Denis Pynkin]

В сообщении от 26 октября 2006 12:53 Mikhail Yakshin написал(a):

> Примерно понятно, насколько я понял - это ведь не какой-то принципиально
> иной шаг сборки требуется - это просто должна быть некая сторонняя
> утилита, которая соберет весь "набор дистрибутивостроителя" для
> дальнейшей консервации. Внутри она может использовать spt-create-repo, а
> может не использовать - т.е. сейчас главное, что ее ничто не будет
> препятствовать написать потом.

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

вот это - принципиально имхо
т.е. заменить $IDENT.packages на $IDENT/* , как это было в separator/spt
тогда можно использовать уже готовые наборы файлов-cgbcrjd и, в зависимости от 
текущей сборки, просто копировать их в каталог $IDENT
к примеру у меня есть 
base - то, что необходимо для всех livecd
kernel-$VERSION - где прописана конкретная версия ядра и сопутствующих 
библиотек
kde, icewm - соответствующие wm
net - доп. утилиты для работы с сетью
ну и так далее...

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

-- 
WBR, d4s

Re: [sisyphus] I: spt3

[Mikhail Yakshin]

Denis Pynkin пишет:
> В сообщении от 26 октября 2006 12:53 Mikhail Yakshin написал(a):
> 
>> Примерно понятно, насколько я понял - это ведь не какой-то принципиально
>> иной шаг сборки требуется - это просто должна быть некая сторонняя
>> утилита, которая соберет весь "набор дистрибутивостроителя" для
>> дальнейшей консервации. Внутри она может использовать spt-create-repo, а
>> может не использовать - т.е. сейчас главное, что ее ничто не будет
>> препятствовать написать потом.
> 
>>> 1. если используется много файлов-списков пакетов, то вызывать придется
>>> для каждого. Вполне возможно, что и каталогов с такими файлами м.б.
>>> несколько - у меня так и было. Причем списки частично пересекаются.
> 
> вот это - принципиально имхо
> т.е. заменить $IDENT.packages на $IDENT/* , как это было в separator/spt
> тогда можно использовать уже готовые наборы файлов-cgbcrjd и, в зависимости от 
> текущей сборки, просто копировать их в каталог $IDENT
> к примеру у меня есть 
> base - то, что необходимо для всех livecd
> kernel-$VERSION - где прописана конкретная версия ядра и сопутствующих 
> библиотек
> kde, icewm - соответствующие wm
> net - доп. утилиты для работы с сетью
> ну и так далее...

Можно сделать и тот, и другой вариант. Большого смысла в этой директории 
я не вижу - лично мне это удобным не кажется, но если кому-то удобно - 
можно сделать проверку, допустим - если $IDENT.packages - это файл - то 
брать из файла. Если это директория - это брать $IDENT.packages/*. Пойдет?

-- 
WBR, Mikhail Yakshin

Re: [sisyphus] I: spt3

[Denis Pynkin]

В сообщении от 26 октября 2006 16:14 Mikhail Yakshin написал(a):

> > т.е. заменить $IDENT.packages на $IDENT/* , как это было в separator/spt
> Можно сделать и тот, и другой вариант. Большого смысла в этой директории
> я не вижу - лично мне это удобным не кажется, но если кому-то удобно -
> можно сделать проверку, допустим - если $IDENT.packages - это файл - то
> брать из файла. Если это директория - это брать $IDENT.packages/*. Пойдет?
да

-- 
WBR, d4s

Re: [sisyphus] I: spt3

[Denis Pynkin]

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

И еще, в догонку ;-)

чего не хватало в separator/spt и пока отсутствует в spt3 - поддержки  
установки на livecd нескольких разных ядер и образов для загрузки.

PS маленькая правка в аттаче для spt-pack-squashfs - не находит созданного 
образа.

-- 
WBR, d4s

[-- Attachment #2: spt-pack-squashfs.diff --]
[-- Type: text/x-diff, Size: 337 bytes --]

--- spt-pack-squashfs.orig	2006-10-26 14:00:36 +0300
+++ spt-pack-squashfs	2006-10-26 15:06:42 +0300
@@ -13,4 +13,4 @@
 	/ /.image $EXTRAOPTS -e /.image /.host /.in /.out /.fakedata /usr/lib*/*fakeroot* \
 	|| Fatal "Unable to create squashfs image"
 
-mv -f $chroot/.image "$out_dir/$OUT/altlinux"
+mv -f $chroot/.image "$out_dir/$OUT"

Re: [sisyphus] I: spt3

[Mikhail Yakshin]

Denis Pynkin пишет:
> И еще, в догонку ;-)
> 
> чего не хватало в separator/spt и пока отсутствует в spt3 - поддержки  
> установки на livecd нескольких разных ядер и образов для загрузки.

А кто/что мешает это сделать? Несколько разных образов, каждый со своим 
ядром - как раз можно сделать очень легко прямо сейчас. Образ с 
несколькими ядрами - да, потребует еще доработки spt-boot-propagator.

-- 
WBR, GreyCat

Re: [sisyphus] I: spt3

[Denis Pynkin]

В сообщении от 26 октября 2006 16:22 Mikhail Yakshin написал(a):

> > чего не хватало в separator/spt и пока отсутствует в spt3 - поддержки
> > установки на livecd нескольких разных ядер и образов для загрузки.
> А кто/что мешает это сделать? Несколько разных образов, каждый со своим
> ядром - как раз можно сделать очень легко прямо сейчас.
используя один профайл ?

> Образ с  несколькими ядрами - да, потребует еще доработки 
spt-boot-propagator.
вообщем куда вносить request-features ? ;-)
на wiki ?

-- 
WBR, d4s

Re: [sisyphus] I: spt3

[Mikhail Yakshin]

Denis Pynkin пишет:
> В сообщении от 26 октября 2006 16:22 Mikhail Yakshin написал(a):
> 
>>> чего не хватало в separator/spt и пока отсутствует в spt3 - поддержки
>>> установки на livecd нескольких разных ядер и образов для загрузки.
>> А кто/что мешает это сделать? Несколько разных образов, каждый со своим
>> ядром - как раз можно сделать очень легко прямо сейчас.
> используя один профайл ?

Да, конечно. Как раз в этом и идея - в одном recipe можно 
последовательно вызвать несколько раз сборку нескольких разных образов, 
примерно так:

spt-init-chroot
spt-make-chroot -o packages=packages1
spt-pack-squashfs -o out_dir=out1
spt-init-chroot
spt-make-chroot -o packages=packages1
spt-pack-squashfs -o out_dir=out2
# + добавить что-то вроде mv out1/* out2
spt-pack-iso

>> Образ с  несколькими ядрами - да, потребует еще доработки 
> spt-boot-propagator.
> вообщем куда вносить request-features ? ;-)
> на wiki ?

Лучше, наверное, FR на пакет spt3 в багзиллу.

-- 
WBR, GreyCat

Re: [sisyphus] I: spt3

[Хихин Руслан]

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

Здравствуйте Mikhail Yakshin
  В сообщении от 26 октября 2006 17:45 Mikhail Yakshin написал(a):
 > Denis Pynkin пишет:
 > > В сообщении от 26 октября 2006 16:22 Mikhail Yakshin написал(a):
 > >>> чего не хватало в separator/spt и пока отсутствует в spt3 -
 > >>> поддержки
 > >>>
 > >>> установки на livecd нескольких разных ядер и образов для
 > >>> загрузки.
 > >>
 > >> А кто/что мешает это сделать? Несколько разных образов, каждый со
 > >> своим
 > >>
 > >> ядром - как раз можно сделать очень легко прямо сейчас.
 > >
 > > используя один профайл ?
 >
 > Да, конечно. Как раз в этом и идея - в одном recipe можно
 >
 > последовательно вызвать несколько раз сборку нескольких разных
 > образов,
 >
 > примерно так:
 >
 >
 >
 > spt-init-chroot
 >
 > spt-make-chroot -o packages=packages1
 >
 > spt-pack-squashfs -o out_dir=out1
 >
 > spt-init-chroot
 >
 > spt-make-chroot -o packages=packages1
 >
 > spt-pack-squashfs -o out_dir=out2
 >
 > # + добавить что-то вроде mv out1/* out2
 >
 > spt-pack-iso
 >
 > >> Образ с  несколькими ядрами - да, потребует еще доработки
 > >
 > > spt-boot-propagator.
 > >
 > > вообщем куда вносить request-features ? ;-)
 > >
 > > на wiki ?
 >
 > Лучше, наверное, FR на пакет spt3 в багзиллу.
В выходные, дай бог, обязательно на него взгляну. :)
Пока по опыту приминения предыдущего: 

 1 Что не хватало в старом, это отсутствие логов, особенно в случае 
неудачной сборки - тот момент на чём "вывалилась сборка", для 
дальнейшего анализа. 
 
 2 В случае отсутствия какого-нибудь пакета - попытка сборки из 
наличного src.rpm.

3 Начальная сортировка пакетов, передаваемых на сборку, с тем, что-бы 
собирать вначале более "простые" по зависимостям пакеты, а потом более 
сложные. (От родителя к потомкам).

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

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

Re: [sisyphus] I: spt3

[Michael Shigorin]

On Thu, Oct 26, 2006 at 10:24:19PM +0400, Хихин Руслан wrote:
> 2 В случае отсутствия какого-нибудь пакета - попытка сборки из
> наличного src.rpm.
> 3 Начальная сортировка пакетов, передаваемых на сборку, с тем,
> что-бы собирать вначале более "простые" по зависимостям пакеты,
> а потом более сложные. (От родителя к потомкам).

Это не к spt*, это к incominger.

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

Re: [sisyphus] I: spt3

[Хихин Руслан]

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

Здравствуйте Michael Shigorin
  В сообщении от 27 октября 2006 00:20 Michael Shigorin написал(a):
 > On Thu, Oct 26, 2006 at 10:24:19PM +0400, Хихин Руслан wrote:
 > > 2 В случае отсутствия какого-нибудь пакета - попытка сборки из
 > >
 > > наличного src.rpm.
 > >
 > > 3 Начальная сортировка пакетов, передаваемых на сборку, с тем,
 > >
 > > что-бы собирать вначале более "простые" по зависимостям пакеты,
 > >
 > > а потом более сложные. (От родителя к потомкам).
 >
 > Это не к spt*, это к incominger.
 Ну, по-моему, хороший spt - это маленький incominger . 
Задачи в принципе аналогичные, только в spt - это разовая задача, а 
incominger - это циклическая и постоянная. 
 Единственно, в них условия разные - в spt -можно задать нужный порядок 
пересборки, а в incominger порядок так напрямую не задашь, т.к. он  
определяется ещё и новизной пакетов, вернее порядком их поступления.
 Для сведения обеих задач к "одному" знаменателю, достаточно ввести 
что-то типа "квантования" процесса построения пакетов и нкоминге, т.е. 
после поступления партии пакетов, за определённый период, должна 
решаться задача, аналогичная SPT, только естественно, без построения 
имиджа диска :)

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

PS Как я понимаю есть устоявшиеся зависимости между пакетами (т.е. 
независимо от версии пакета, например, пакет mc в настоящее время 
зависит от libslang). Эти зависимости не меняются со временем (меняются 
очень медленно), и если у пакета появились вдруг новые зависимости, то 
скорей-всего это ошибка сборки. Моя мысль заключается в том, что т.к. 
эти зависимости повторяются, то порядок поступления пакетов на сборку 
меняется достаточно редко, т.е. если решить задачу сортировки пакетов 
по "весу" зависимости, (0 - не зависит не от кого, 10 - имеет 
максимальную длину зависимости в 10 пакетов), то это решение можно 
применять не один раз, а следовательно, можно задать каждому пакету 
("условное" место в очереди зависимостей). 
http://lists.altlinux.org/pipermail/devel/2006-October/037806.html

PPS Тут посмотрел на mc - и ни как не могу понять - как он от chkconfig 
начал зависеть :)

rpm --requires mc
chkconfig
libslang >= 1.4.9
/bin/sh
/bin/sh
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
coreutils
gawk
grep
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.1.1)
libc.so.6(GLIBC_2.2)
libc.so.6(GLIBC_2.2.1)
libc.so.6(GLIBC_2.3)
libc.so.6(GLIBC_2.3.4)
libc.so.6(GLIBC_2.4)
libext2fs.so.2
libglib-2.0.so.0
libgpm.so.1
libslang.so.1
perl(File/Basename.pm)
perl(File/Temp.pm)
perl(POSIX.pm)
perl(bytes.pm)
perl-base
rpm
rtld(GNU_HASH)
sed
sh

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

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

Re: [sisyphus] I: spt3

[Mikhail Yakshin]

Хихин Руслан wrote:
> Здравствуйте Michael Shigorin
>   В сообщении от 27 октября 2006 00:20 Michael Shigorin написал(a):
>  > On Thu, Oct 26, 2006 at 10:24:19PM +0400, Хихин Руслан wrote:
>  > > 2 В случае отсутствия какого-нибудь пакета - попытка сборки из
>  > >
>  > > наличного src.rpm.
>  > >
>  > > 3 Начальная сортировка пакетов, передаваемых на сборку, с тем,
>  > >
>  > > что-бы собирать вначале более "простые" по зависимостям пакеты,
>  > >
>  > > а потом более сложные. (От родителя к потомкам).
>  >
>  > Это не к spt*, это к incominger.
>  Ну, по-моему, хороший spt - это маленький incominger . 
> Задачи в принципе аналогичные, только в spt - это разовая задача, а 
> incominger - это циклическая и постоянная. 

Вы что-то путаете. spt вообще не занимается сборкой пакетов. Для этого
есть hasher, incominger, gear, есть или планируются какие-то более
хитрые обвязки к git и т.п.

-- 
WBR, Mikhail Yakshin

Re: [sisyphus] I: spt3

[Хихин Руслан]

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

Здравствуйте Mikhail Yakshin
  В сообщении от 27 октября 2006 20:53 Mikhail Yakshin написал(a):
 > Хихин Руслан wrote:
 
 >
 > Вы что-то путаете. spt вообще не занимается сборкой пакетов. Для
 > этого
 >
 > есть hasher, incominger, gear, есть или планируются какие-то более
 >
 > хитрые обвязки к git и т.п.

Это, просто означает, что то, что мне нужно, не будет называться spt3, 
хотя конечным продуктом, всё равно будет собранный дистрибутив (Live 
или Install) :)

Другими словами : 
Как раз то, что он не занимается сборкой пакетов, мне и не хватает :)
-- 
С  уважением Хихин Руслан

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

Re: [sisyphus] I: spt3

[Michael Shigorin]

On Sat, Oct 28, 2006 at 09:04:12AM +0400, Хихин Руслан wrote:
> Другими словами : Как раз то, что он не занимается сборкой
> пакетов, мне и не хватает :)

Так это в другую сторону (или от другого кода).
Спрашивать осмысленно legion@.

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

Re: [sisyphus] I: spt3

[Dmitry V. Levin]

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

On Thu, Oct 26, 2006 at 10:24:19PM +0400, Хихин Руслан wrote:
[...]
>  > Лучше, наверное, FR на пакет spt3 в багзиллу.
[...]
>  2 В случае отсутствия какого-нибудь пакета - попытка сборки из 
> наличного src.rpm.

Формирователь чего-либо из репозитория пакетов не должен собирать
пакеты - это совершенно отдельная задача.


-- 
ldv

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

Re: [sisyphus] spt-boot-propagator was: Re: I: spt3

[Mikhail Yakshin]

Denis Pynkin wrote:
> В сообщении от 26 октября 2006 16:45 Вы написали:
> 
>>> вообщем куда вносить request-features ? ;-)
>>> на wiki ?
>> Лучше, наверное, FR на пакет spt3 в багзиллу.

Надеюсь, не будете возражать, если я верну дискуссию в sisyphus@, что
все могли участвовать?

> #10193
> 
> сижу и ковыряю spt-boot-propagator, поэтому появляются вопросы и предложения. 
> Если есть возможность - прокомментируйте пожалуйста.
> 1. насколько я понимаю $tmp_dir/modules нигде не используется. Планируется ли 
> его использование в дальнейшем ?

Пока нет, все, что нужно пока - это получить mar-архив для упаковки в
initrd пропагатора.

> 2. есть ли планы по использованию других загрузчиков, кроме isolinux ? 

Да, уже готов в принципе вариант для деплоймента lilo. Он, правда, более
хитрый - из двух частей как бы состоит. Я попробую в ближайшее время
сделать iso-диск, который умеет загружаться а ля livecd и ставиться с
помощью spt-deploy-lilo.

> 3. формат переменной KERNEL останется таким как сейчас ? нужно для выбора 
> дефолтного загрузочного ядра

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

> PS по мере изучения постараюсь добавить замеченые баги
> 1. не удаляется /.isolinux/modules после создания full.cz - поэтому попадает 
> на iso. #10194
> 2. 2 раза вызывается генерация boot stuff. #10195

Ok, будет разгребать.

> PPS переделал spt-boot-propagator для корректной работы с несколькими ядрами 
> (полученный скрипт в аттаче). Пока что не решена проблема именования ядра и 
> соответствующего full.cz :-(
> В моем варианте isolinux их не находит. Если вручную задать что-то покороче, 
> то все работает отлично.

Попробуем mangle'ить, если понадобится.

> Вообщем надеюсь на совет - как их лучше генрировать. Пока что склоняюсь к 
> тому, чтобы пропустить имя через sed и убрать '-' и '.' из имен. Получается 
> что-то тапи такого - "vmlinuz2616wks26smpalt8" и 
> такого - "full2616wks26smpalt8.cz", но по крайней мере работает ;-)

На "_" заменять может быть?

> в планах на завтра - переделать еще и "spt-pack-iso" для корректной работы с 
> несколькими ядрами. Поэтому сразу вопрос - насколько правильно, с 
> идологической точки зрения, если генерировать isolinux.cfg динамически, хотя 
> бы частично ?

По идее бы его вообще целиком динамически генерировать стоило - там
интересного для настраиваек пользователем вроде бы минимум. Распилить по
хорошему бы spt-boot-propagator и сделать, в частности,
spt-boot-isolinux. Тем более spt-boot-propagator - он сейчас сильно
много лишнего делает.

> PPPS spt3 очень удачный получился, по сравнению с предыдущими версиями ;-) 
> намного проще разбираться и добавлять свои фичи. Спасибо за проделанную 
> работу.

Вам спасибо за проявленный интерес и дельные комментарии :)

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