[devel-distro] DE nightly builds

[devel-distro] DE nightly builds

[Aleksey Novodvorsky]

Коллеги, по мере приближения p7, мы планируем систематизировать и
автоматизировать сборку образов для тестирования. В частности, речь
идет о регулярных сборках поддерживаемых в Сизифе desktop environment,
до сих пор этим занимался mike@. Некоторые предложения по составу
сборок я написал на вики:
http://www.altlinux.org/Регулярные_сборки_образов . Особенно они
касаются мейнтейнеров DE.
Прошу прочитать внимательно и до конца, постараться понять смысл,  а
если будут замечания и предложения по существу, то лучше обсудить их
тут или внести в раздел "обсуждения" на вики, но не сразу править
текст.
Текст в основном согласован с mike@, но у нас остаются небольшие разногласия.
Спасибо.

Rgrds, Алексей

Re: [devel-distro] DE nightly builds

[Michael Shigorin]

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/