* Re: [devel-distro] DE nightly builds
2012-12-15 14:16 [devel-distro] DE nightly builds Aleksey Novodvorsky
@ 2012-12-15 16:11 ` Michael Shigorin
0 siblings, 0 replies; 2+ messages in thread
From: Michael Shigorin @ 2012-12-15 16:11 UTC (permalink / raw)
To: devel-distro
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 <mike@altlinux.ru>
------ Linux.Kiev http://www.linux.kiev.ua/
^ permalink raw reply [flat|nested] 2+ messages in thread