From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <457B5ADB.60003@altlinux.org> Date: Sun, 10 Dec 2006 03:54:51 +0300 From: Mikhail Yakshin User-Agent: Thunderbird 1.5.0.5 (X11/20060822) MIME-Version: 1.0 To: ALT Devel discussion list References: <20060910185913.GD22147@localhost.localdomain> <20061107203400.GC13108@localhost.localdomain> <20061107220921.GA29276@basalt.office.altlinux.org> <200612091229.27126@ruslandh> In-Reply-To: <200612091229.27126@ruslandh> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Subject: Re: [devel] spt/spt3 X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.9rc1 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Dec 2006 00:55:18 -0000 Archived-At: List-Archive: List-Post: Приветствую! > Попробовал объединить оба пакета 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]