From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on sa.int.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.5 Date: Sat, 15 Dec 2012 18:11:44 +0200 From: Michael Shigorin To: devel-distro@lists.altlinux.org Message-ID: <20121215161144.GF10780@osdn.org.ua> Mail-Followup-To: devel-distro@lists.altlinux.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.1i Subject: Re: [devel-distro] DE nightly builds X-BeenThere: devel-distro@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: shigorin@gmail.com, Distributions development List-Id: Distributions development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 16:11:50 -0000 Archived-At: List-Archive: On Sat, Dec 15, 2012 at 05:16:54PM +0300, Aleksey Novodvorsky wrote: > http://www.altlinux.org/Регулярные_сборки_образов [...] > Текст в основном согласован с mike@, но у нас остаются > небольшие разногласия. Пожалуй, мне пора исправить свои недоработки, которые привели к таким разногласиям -- бишь пояснить свои соображения и спросить совета, нет ли в них ошибок. Алексей предложил внести в т.ч. synaptic в метапакеты $DE-default, на что я заметил, что это не специфика DE, а как раз специфика набора дистрибутивов, к которому предъявляются определённые требования или пожелания (в данном случае описанные по ссылке выше, в случае школьного комплекта -- свои, и так далее). Одной из осознанных изначально целей создания mkimage-profiles при живых и здравствующих семействах mkimage-profiles-desktop, mkimage-profiles-office-server, spt-profiles-junior{,-school} и подобных была возможность ясно выделить общее и особенное, при этом тратя минимум усилий на описание особенного поверх наиболее подходящего общего. Чтоб на форках экономить. То есть задумка -- это конструирование образов по их желаемым свойствам, которое отчасти получилось сделать в m-p-d (use.mk.in), но лишь до степени повторного использования "кирпичиков" вроде use-pspo, а не полных и самостоятельных дистрибутивов. Соответственно и надеюсь потихоньку привести взаимодействие майнтейнеров и релиз-менеджеров к тому, чтобы внимание уделять собственно интересующей цели, а не подпиранием костылями соседа (сейчас нередко RM делает хуками то, что не сделано или сделано не так в пакетах, а майнтейнер думает о том, что как раз удобней сделать в профилях и не повторять из метапакета в метапакет). В данном случае итоговым результатом предполагается набор образов с некоторым набором заданных и разделяемых свойств; в терминах m-p это описывается как некий промежуточный образ -- distro/.regular, например -- для которого эти свойства определены при помощи: - образа, на котором он сам базируется; - затребованных фич; - указанных списков пакетов, в т.ч. при помощи выборки по тегам: например, $(call tags,(desktop || mobile) && mate) -- и далее поверх такой общей базы можно формировать целевой набор, включающий нужные DE и приложения. Касательно того, где лучше определять набор пакетов приложений, однозначного ответа у меня нет. По крайней мере точно известно, что в сообществах разработчиков и пользователей разных DE есть свои предпочтения и соответственно те "общие" приложения, которые рекомендуются к использованию с тем же LXDE, имеют больше шансов более качественно с ним работать (хотя бы быть более тщательно оттестированными в таком сочетании). Наверное, такие "сателлиты" стоит включать в DE-специфические метапакеты и знает о них лучше майнтейнер. А вот о том, какие приложения пользователь рассчитывает увидеть (или наоборот -- находит излишними) в более-менее любом образе, майнтейнер DE знать может, но не обязан; такие наборы далее можно классифицировать по тулкитам или ресурсоёмкости. Если их оформлять метапакетами, то на каждое изменение строчки придётся делать пересборку (такую технологию уже проходили). Если пакаджлистами -- знание о сочетании оказывается "замкнуто" в профиле и не может быть без хотя бы минимальных усилий человека применено в другом профиле либо на установленном дистрибутиве. Это обычный tradeoff, но его стоит хорошо понимать :) В качестве второго примера, который стоит оформлять метапакетами, как раз и подходит композитный менеджер: их есть несколько и то, какой подходит/совместим с конкретным DE, лучше знать майнтейнеру. PS: в mkimage-profiles есть встроенный анализатор дублей в списках пакетов, вызывается как make -C pkg.in/lists pkgdups; повторы сами по себе не особо страшны, интересней "ходячие кластеры" (например, firefox-* или alterator-*) -- такой скрипт ещё предстоит написать. -- ---- WBR, Michael Shigorin ------ Linux.Kiev http://www.linux.kiev.ua/