Планы, определяющие функциональность релиза Debian 7 "Wheezy"

Анонсированы [3] первые планы подготовки будущего стабильного релиза Debian 7 "Wheezy". После неудачной попытки перехода на фиксированный по времени график подготовки релизов, в качестве наиболее реальной даты выхода новой версии называется конец 2012 или начало 2013 года.
Среди первичных задач, которые разработчики планируют реализовать в Debian 7, упомянуты [4]:

• Из уже ранее реализованных в Squeeze целях, которые будут учтены в следующем релизе, упомянуты:
  • Увеличение [5] скорости загрузки за счет учета зависимостей между init-скриптами и организации параллельного запуска сервисов (переход на insserv и переработанные скрипты инициализации rc-sysv). Среди нерешенных задач остается вопрос использования по умолчанию быстрого и упрощенного командного интерпретатора dash, решение оставшихся проблем с параллельной загрузкой, учитывающей зависимости;
  • Улучшение [6] качества пакетов в репозиториях Debian: обнаружение и исправление ошибок, гарантия отсутствия непригодных [7] для установки пакетов и пакетов при использовании которых наблюдается конфликт из-за создания одних и тех же имён файлов;
  • Удаление [8] из поставки устаревших библиотек, таких как GLib 1.2. Полный список библиотек, которые будут признаны устаревшими пока не сформирован;
  • Продолжение перевода пакетов на усовершенствованный формат DebSrc 3.0, в котором патчи можно размещать в виде отдельных файлов внутри директории "debian/patches/";
• Цели которые начали реализовывать в рамках подготовки Squeeze, но планируют довести до конца в Wheezy:
  • Поддержка [9] многоархитектурных установок (Multiarch), дающих возможность размещения в системе заголовочных файлов и библиотек, параллельно доступных для нескольких аппаратных архитектур;
  • Продолжение развития архитектуры kFreeBSD [10], сочетающей в себе ядро FreeBSD с пользовательским окружением на базе glibc и GNU-утилит. Главной задачей является уменьшение числа непригодных к установке пакетов до величин, приемлемых для стабильного релиза. Например, в текущем состоянии невозможно [11] установить X-сервер из-за проблем с HAL;
  • Обеспечение поддержки [12] IPv6 во всех приложениях из состава дистрибутива, которые могут работать через IPv4. В настоящее время проблемы наблюдаются в достаточно широком спектре программ, среди которых: Squid, MySQL, Asterisk, ISC DHCP, openvpn, uucp, avahi и т.д.
  • Поддержка работы с файлами большого размера во всех пакетах (некоторые программы не читают файлы больше 2/4 Гб). Проблемы наблюдаются [13] в таких пакетах, как php5, navit, qdbm, audiofile, lua50, dvd+rw-tools, icedove, alpine, nautilus, kpart-webkit, kopete, thttpd, tetex и т.д.
  • Удаление неиспользуемых файлов "*.la", приводящих [14] к возникновению лишних зависимостей, чистка поля dependency_libs в оставленных файлах;
• Новые цели, утвержденные для реализации в Wheezy:
  • Внедрение [15] новой корневой директории "/run", в которую будет перенесено содержимое "/var/run" с целью решения проблемы с недоступностью /var/run на ранней стадии загрузки. Подробное обоснование целесообразности подобного шага можно прочитать здесь [16];
  • Прекращение [17] использования API Video4Linux 1 (V4L1), поддержка совместимости с которым была прекращена в новом драйвере для захвата видео, поддерживающем только V4L2. В настоящее время устаревшее API используется в 70 пакетах. В качестве возможного варианта решения проблемы может быть использована библиотека libv4l, эмулирующая V4L1 через V4L2;
  • Прекращение [18] использования /dev/dsp. Несмотря на то, что подсистема OSS уже не поддерживается в ядре Linux, многие приложения по прежнему используют /dev/dsp для вывода звука. В качестве решения проблемы могут быть использованы специальные врапперы или модуль snd-pcm-oss эмулирующий работу /dev/dsp поверх ALSA;
• Цели, решение по которым не принято окончательно:
  • Интеграция поддержки системы принудительного контроля доступа SELinux;
  • Использование по умолчанию DNSSEC в конфигурациях рабочих станций;
• Цели, отвергнутые для реализации в Wheezy:
  • Использование Grub 2 в качестве загрузчика по умолчанию во всех возможных ситуациях. В настоящее время поддерживается как GRUB Legacy, так и GRUB 2, при этом GRUB 2 выбирается по умолчанию в grub-installer, за исключением случаев использования multipath и dmraid. Цель отклонена, так как не может считаться глобальной задачей для релиза, скорее это текущая доработка;
  • Использование по умолчанию Python 2.7 (уже используется по умолчанию, осталось доработать некоторые пакеты);
  • Создание тестовых наборов для контроля качества на этапе сборки пакетов (отсутствует разработчик);
  • Создание тестовых наборов для контроля качества при выполнении программ (отсутствует разработчик);
  • Реализация предварительного варианта спецификации FHS 3.0 [19] (Filesystem Hierarchy Standard), определяющей набор и место размещения в файловой системе стандартных утилит, системных файлов и директорий.

Дополнительно можно отметить обновления таблицы [20] с оценкой статуса поддерживаемых архитектур. Из официально поддерживаемых архитектур отмечены: amd64, armel, hurd-i386, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, sparc. Наибольшее число проблем связано с архитектурой hurd-i386 базирующейся на ядре GNU/Hurd. Несмотря на то, что для работы в Debian GNU/Hurd адаптировано 68% из всех находящихся в дистрибутиве пакетов и не до конца реализована инфраструктура сборки, разработчики проекта настроены [21] оптимистично и намерены довести качество до нужного уровня.
Среди других возможностей оптимизации подготовки релиза отмечается поиск новых путей оптимизации процесса тестирования ветки Debian Testing. Например, упоминается рассмотрение возможности использования некоторых идей из проекта CUT [22] (Constantly Usable Testing, постоянно обновляемые и пригодные к использованию снапшоты Debian Testing) и ветки с непрерывным циклом обновления [23]. В частности, планируется упростить использование срезов экспериментальной ветки, используя которые можно опробовать новые возможности.
Также ведутся работы по наглядному выделению периодического временного удаления пакетов из ветки Testing: будет создана утилита, которая даст возможность оценить какие из пакетов отсутствуют в ветке, а какие могут быть потенциально удалены при выполнении определенных действий. Ежедневно в списке рассылки debian-devel будут публиковаться списки планируемых ко временному удалению пакетов. К сожалению пока не найдено альтернативного способа обеспечения в репозитории гарантированной непротиворечивости пакетов и связанных с ними зависимостей, не требующего временного удаления пакетов из Testing в процессе обновления пакетов, требующих корректировку зависимостей у других пакетов (transitions), с целью гарантирующих целостность и непротиворечивость пакетов и связанных с ними зависимостей.