[sisyphus] I: spt3

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

Здравствуйте 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

-- 
С  уважением Хихин Руслан
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/sisyphus/attachments/20061027/28fe18e9/attachment-0003.bin>