Разработчики Fedora Linux опубликовали список пакетов, которые претендуют на удаление из репозиториев Fedora из-за отсутствия активного мэйнтейнера или длительных проблемам со сборкой. Всего в списке представлено 129 пакетов, среди которых такие приложения, как Compiz, Netbeans, avant-window-navigator, gnome-paint, intellij-idea, tklib, tcllib и tomcat5. Если до 7 февраля для указанных пакетов не найдётся мэйнтейнер, то они не войдут в состав Fedora 17.

Источник: http://www.opennet.ru/opennews/art.shtml?num=32987

В связи с волной необоснованной критики Леннарт Поттеринг (Lennart Poettering) подготовил сводный документ, в котором обобщил мотивы переноса содержимого /bin и /lib в директорию /usr в грядущем релизе Fedora 17, а также опроверг наиболее часто встречающиеся мифы. По словам Поттеринга, новое унифицированное расположение исполняемых файлов и библиотек внутри раздела /usr (содержимое /bin планируется перенести в /usr/bin, /sbin в /usr/sbin, /lib в /usr/lib и /lib64 в /usr/lib64) более совместимо с UNIX, чем практикуемый в Linux подход с разделением на /bin и /usr/bin (в SysV Unix /bin является симлинком на /usr/bin).

Некоторые плюсы переноса компонентов из корня в /usr:

• В настоящее время разные дистрибутивы Linux и Unix-системы по разному формируют состав /bin и /usr/bin. Перенос всех исполняемых файлов в /usr/bin и наполнение /bin через символические ссылки позволит избежать путаницы и сохранить совместимость с ранее практикуемым методом.
• Все устанавливаемые из RPM-пакетов неизменные компоненты будут сосредоточены только внутри раздела /usr и не будут встречаться за его пределами, что позволит упростить организацию бездисковых систем и повысит их безопасность - для работы достаточно будет экспортировать в режиме только для чтения раздел /usr и централизованно обновлять его, не заботясь о необходимости синхронизации содержимого каталогов /bin, /sbin и /lib. В корне останутся только файлы, связанные с загрузкой и специфичные для текущей машины данные, например, файлы конфигурации, логи и файлы с меняющимися данными (/etc, /root, /var, /run).
• Возможность использования нескольких разделов /usr для загрузки разных версий или состояний дистрибутива, например, в процессе обновления можно сохранить старое содержимое в отдельном разделе и вернуться на него в случае проблем. Возможна также реализация схемы при которой имеется две копии содержимого /usr, активная копия монтируется в режиме только для чтения, а в неактивную устанавливается обновление, после чего директории меняются местами и синхронизируются;
• Упрощение формирования гостевых окружений для систем виртуализации - достаточно монтировать внутри виртуальных окружений системный раздел /usr в режиме только для чтения. При этом автоматически решаются проблемы с обновлением начинки гостевых систем и существенно экономится дисковое пространство;
• В качестве примера успешной унификации доступа к исполняемым файлам приводится Solaris 11, в котором все стандартные программы сосредоточены только в разделе /usr;

Источник: http://www.opennet.ru/opennews/art.shtml?num=32914

В списке рассылки разработчиков Fedora вспыхнуло активное обсуждение возможности создания специальной версии Fedora с непрерывным циклом обновления пакетов (Rolling-release), при котором обновления версий программ производятся постоянно, не дожидаясь фиксированных релизов дистрибутива. В качестве примеров проектов, в которых применяется непрерывный цикл выпуска обновлений, можно отметить Arch Linux, Gentoo, Debian CUT и openSUSE Tumbleweed, в которых пользователь в любой момент имеет возможность перейти на самые свежие версии программ.

В настоящее время при подготовке релизов уже используется экспериментальный репозиторий Rawhide, который развивается в рамках непрерывного цикла выпуска обновлений. Но для конечных пользователей Rawhide не подходит, так как стабильность пакетов в нём оставляет желать лучшего, а при значительных обновлениях, таких как переход на новые версии ядра, системных библиотек и графических окружений, могут наблюдаться проблемы с работоспособностью. Rawhide позиционируется как ветка, созданная исключительно для разработки и тестирования новых возможностей и исправлений, которые часто вносятся туда без всякого предварительного тестирования и проверки. Поэтому некоторые пакеты в Rawhide часто находятся в нерабочем состоянии, и даже более того, эти эксперименты могут привести к потере данных.

Одним из наиболее интересных предложений, прозвучавших в процессе обсуждения, является использование комбинированной схемы, которая позволит сохранить необходимый уровень стабильности дистрибутива, обеспечив при этом возможность использования новых версий графических программ. Схема предусматривает разделение частей дистрибутива на три категории: ядро дистрибутива (ядро Linux, glibc, gcc, системные библиотеки, shell), системные компоненты (X11, KDE, GNOME, XFCE, Perl, Python) и пользовательские компоненты (офисные пакеты, браузеры и графические редакторы). Ядро дистрибутива предлагается обновлять раз в 12-18 месяцев, системные компоненты - раз в полгода, а не связанные большим числом зависимостей пользовательские приложения обновлять по мере выхода новых версий, после проведения минимальной стабилизации в тестовых репозиториях.

Дискуссия о том, какой же конкретно подход в реализации цикла непрерывных обновлений выбрать и нужен ли он вообще ещё продолжается. На данный момент нет никакого окончательного решения на этот счёт, ясно лишь одно: для этой затеи остро не хватает человеческих ресурсов. Все изменения в этой области пока не уходят дальше слов, у существующих разработчиков Fedora много своих дел, поэтому сами они не спешат в этой области вводить какие-то новшества.

Источник: http://www.opennet.ru/opennews/art.shtml?num=32892