Маскировка пакетов в Gentoo

полный отстой и безперспективняк.

gentoo-based

кстати если не добавишь тег gentoo, будешь общаться только со мной.

почему? потому что технчиески неосуществимо, или потому что потребует больше усилий, чем усилия необходимые на поддержку дистрибутива без релизов?

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

Ошибаешься, кастует, вот только что скастовало опять.

По теме: это никому не нужно, всех устраивает как есть, а есть — хорошо и удобно. Кстати ты веточки-то еще чуток не разбавил, каждый релиз будет: multilib, no-multilib, x32? Кстати каждый из будет в hardened?

ты веточки-то еще чуток не разбавил

Значит переделать надо.

multilib, no-multilib, x32, hardened
вот это всё надо реализовать на USE-флагах и наборах пакетов

Ты мешаешь тёплое с мягким: ветки существует для разных архитектур, но момент стабилизации (время размаскировки ebuild'а) для них не совпадает.

ветки существует для разных архитектур

то есть, это наборы флагов для утилит тулчейна. Не понимаю, что мешает описывать в профилях (profile specifies default values for most variables found in /etc/portage/make.conf, and defines a set of system packages).

Займись лучше спортом.

Проще(?) сказать, что сущуствует некий пакет (с атрибутикой типа версии, релиза), стабильный для архитектуры А, но нестабильный для архитектуры Б. Однако его зависимости в архитектуре А нескольколько отличаются от зависимостей в архитектуре Б (со своей атрибутикой). Разветвлённость зависимостей не даёт возможности создать фиксированные профили по типу «релизов».

зависимости в архитектуре А отличаются от зависимостей в архитектуре Б

Это значит, что архитектуру надо указывать прямо на зависимости.

стабильный для архитектуры А, но нестабильный для архитектуры Б.

а когда пакет станет стаблиным для двух архитектур - что с зависимостями произойдет?

Мне кажется ты где-то путаешься

Это значит, что архитектуру надо указывать прямо на зависимости.

Зависимость и так указывает на свою архитектуру.

а когда пакет станет стаблиным для двух архитектур - что с зависимостями произойдет?

Просто совпадут по версиям. Без спецэффектов.

Зависимость и так указывает на свою архитектуру.

тогда нет проблем с созданием релизов.

Релизы полностью замещают собой пару «стабильное»-«нестабильное», так как их больше по количеству.

Я не понял, а зачем нам нужен второй Debian?

привычка к командам определенного пакетного менеджера. Всё из-за неё.

И эти, USE-флаги. В Debian их нет.

Зависимость и так указывает на свою архитектуру.

Зависимость

Ты отличаешь единственное и множественное число? Я говорю, что не существует изоморфизма из множества А в множество В. В разных архитектурах деревья зависимостей вообще могут быть разными, как в стабильных, так и нестабильных ветках! Просто для одной архитектуры программы из пакетов нестабильной ветки могут выполняться (но могут и глючить) _подобно_ программам из стабильной.

В разных архитектурах деревья зависимостей вообще могут быть разными, как в стабильных, так и нестабильных ветках!

что ты так нервничаешь. Запишешь в пакет зависимость нельсколько раз с разными спецификациями архитектур. Получится мультиграф.

конкретную архитектуру выбирать USE-флагом и нет проблем

вместо того, чтобы обновлять версии программ - бекпортировать патчи для уже установленных версий

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

Ладно, do it. Pinkbyte, хелп ми!

конкретную архитектуру выбирать USE-флагом и нет проблем

https://www.youtube.com/watch?v=BNsrK6P9QvI

стабильная и экспериментальная

Более чем достаточно. Есть профили, с помощью которых можно сделать генту чуть более стабильной или чуть более экспериментальной.

stage3 релизить один раз в начале года

А тот, кто решит установить его в середине или конце года, должен убить неделю на то, чтобы разрулить блоки/маски из-за кучи изменений в дереве портажа?

можно собирать статистику

Кому это нужно?

Это роллинг-релиз, вообще-то. Не надо его портить. То, о чём ты говоришь, требует таких сил, которых у сообщества gentoo нет. А то, что ты хочешь, есть в бинарных дистрибутивах, таких, как CentOS и RHEL.

вместо того, чтобы обновлять версии программ - бекпортировать патчи для уже установленных версий

Какие именно патчи и зачем их бэкпортировать?

Почему просто не обновлять пакеты с исправлениями из апстрима? Там фиксов больше всего.

Что делать с этими патчами через год?

Я в debian видел 2 вида debian-специфичных багов:

- устаревшие пакеты, в новых всё исправлено и работает (openldap, sarg, squid)

- криво бэкпортированные патчи, ломающие пакет (xinetd, openvpn, gcc, glibc, kernel)

Что если сделать их больше?

Подгони больше разработчиков и тестеров - сделаем, делов-то.

Я уже объяснил почему твоя идея не взлетит.

Ты разделом не ошибся?

Советую почитать этот пост:
http://dberkholz.com/2015/01/13/gentoo-needs-focus-to-stay-relevant/

Коротко:

So I’ve come up with three specific use cases for Gentoo that I’d like to see us focus on:
People developing software
People who need extreme flexibility (embedded, etc.)
People who want to learn how Linux works

Желание слепить новый форк никакой практической пользы для сообщества не принесет.

1) Никому не нужен ещё один протухший дебиан
2) У проекта будет 2.5 мейнтейнера

Почитай последние посты Civil в соседней теме про форк Gentoo.

Плюсую пост Донни - человек >10 лет в проекте, он что-то уж точно подозревает :-)