Community репозитории в дистрибутивах

https://wiki.archlinux.org/index.php/Community_repository#community

Some of these packages may eventually make the transition to the core or extra repositories as the developers consider them crucial to the distribution.

Могу попытаться разъяснить про Debian. В Debian все репозитории (main, contrib, non-free) поддерживаются сообществом, так как Debian разрабатывается сообществом. Ветки же contrib и non-free отделены из-за лицензионных проблем. non-free включает в себя пакеты, которые не удовлетворяют условиям DFSG (Debian free software guidelines), а в contrib – пакеты, которые сами-то свободные, но для сборки или для работы которых нужны пакеты из non-free.

поддерживаются сообществом, так как Debian разрабатывается сообществом

Это практически во всех дистрибутивах тогда о_О Но есть те, кто имеет доступ внесения изменений в репу - официальные ментейнеры/разработчики.

в contrib – пакеты, которые сами-то свободные, но для сборки или для работы которых нужны пакеты из non-free.

спасибо, теперь понятно.

Угу, поэтому и интересно, как понять важен пакет для дистрибутива или нет и кто и как это решает?

Понятно, что основные DE важны, но не всегда.

Был в заморозке чтоли? Это и есть самая главная проблема репозиториев, что непонятно кто и как их наполняет, много софта в главных репозиторях находится только по причине того, что они десятки лет назад появились, когда репозитории только формировали и туда брали все. Некоторый софт может быть даже заброшен, но его будут продолжать включать в репы. А вот новому софту пробиться в оффрепы крайне сложно, даже если это полезный и активно развивающийся софт.

Да и вообще вопрос где пороводить границу репозиториев сообщества. Для арча это не только AUR, но и Community. В убунте только main официально поддерживается, а universe поддерживается сообществом. И сопровождение софта в репах сообщества производится куда хуже, в том числе это касается наличия уязвимостей.

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

Как пакеты попадают в основные репы Debian и Arch даже предположить не могу: достаточно ли для этого воли одного из разработчиков или это коллективное решение? Но я не знаю здесь ни одного ментейнера этих дистрибутивов.

Относительно Rosa, может быть Pulfer может пролить свет на данный вопрос.

В Gentoo, по моему опыту, для того, чтобы пакет оказался в основном дереве достаточно чтобы им заинтересовался кто-то из действующих разработчиков или проектов и добавил в дерево. Или кто-то из пользователей предложит пакет через проект proxy maintainers: поддерживать его будет сам пользователь (включая обновления, закрытие багов и пр.), но под присмотром разработчиков; если в багзилле скопится много багов, на которые никак не реагируют, то пакет удалят из дерева.

В Arch это пакеты принятые из AUR некими Trusted Users, которые ещё не «ментейнеры/разработчики»

Trusted Users - так-то вполне себе мейнтейнеры. Мейнтейнеры АУРа.

которых в тоже время, насколько я понял, непонятно самих кто контролирует в плане качества скриптов, которые ими пишутся.

В АУРе есть голосовалка по каждому пакету. Юзвери контролируют. Плюс чтобы стать TU дополнительно нужно заручиться поддержкой хотя бы двух существующих TU.

AUR всё равно не основной репозиторий, а сторонний. Меня интересовал контроль со стороны официальных ментейнеров дистрибутива и принятие решения о переносе пакета в main или extra. Может у кого есть удачный опыт в этом плане?

В core и extra переносит специальная команда, состоящая в т.ч. из официальных мейнтейнеров дистрибутива.

Ветки же contrib и non-free отделены из-за лицензионных проблем. non-free включает в себя пакеты, которые не удовлетворяют условиям DFSG (Debian free software guidelines)

Лицензионность шагает в ногу с лицемерием.

Как пакеты попадают в основные репы Debian и Arch даже предположить не могу: достаточно ли для этого воли одного из разработчиков или это коллективное решение?

В Debian можно выделить:

• Debian Developer - DD. Такие разработчики имеют доступ ко всему архиву Debian.

• Debian Maintainer - DM. У таких разработчиков есть права загрузки только определённых пакетов.

• Sponsored Maintainer. У них прав на загрузку в архив нет - вместо них её осуществляет (после проверки) ментор с правами DD.

(Продвижение новых членов сообщества происходит по этой схеме снизу вверх.)

Соответственно, загрузить новые пакеты в архив могут только DD.

Лицензионность шагает в ногу с лицемерием.

И в чём же здесь лицемерие?

Спасибо за пояснения.

То есть отдельный разработчик под свою ответственность не может принять пакет в основные репы?

Отдельный разработчик - нет.

Посмотрел официальный репозиторий Centos: не нашел там fmt, eigen, sundials, gtest (googletest). Наличие менее распространённых вещей даже страшно проверять. Всё вынесено либо в epel, либо powertools или ещё куда.

в арче есть community репозиторий, а есть aur - это что-то типа openbsd-wip / netbsd-wip

в Debian contrib - это части, где нужны несвободные компоненты (из non-free, или вообще не распространяемые). есть main, где свободные компоненты, есть contrib - которые сами по себе свободные (например, это может быть скрипт из двух строчек, скачивающий что-нибудь несвободное из интернета, или свободный движок для несвободных данных из non-free), и есть non-free, где несвободное, но позволяющее себя опакечивать. коммунити в дебиан это mentors, и, если я правильно понимаю, ещё и ftp-master, впрочем я сам не помню, а попытавшись разобраться в этих сайтах, сам запутался

Относительно Rosa, может быть Pulfer может пролить свет на данный вопрос.

Разные люди собирают пакеты на ABF в частные репозитории, некоторые делают пулл-реквесты, - те из них, кто хорошо себя зарекомендовали, получают доступ к официальным репозиториям (при желании могут и не в Contrib что-то пособирать, но тогда надо оформлять QA-запросы). Ну и сборка в Contrib всё-таки не бесконтрольная - мейнтейнеры смотрят, кто и что собирает. Разве что тестирование непосредственно функционала на совести того, кто собирает в Contrib.