Здравствуйте! В Вт, 11/10/2016 в 22:45 +0300, Hihin Ruslan пишет: > > ... > Но возможно, стоит вначале продумать назначение ветки tx и путь  > попадания пакетов в ветку px.  > Мне кажется, сейчас путь не очень логичен. Наверное, было-бы  > правильнее, что-бы  пакеты в ветку pх попадали из ветки tx, а не  > напрямую.   >  Насколько помню основную идею, ветки pN - это база для выпуска  официальных дистрибутивов. Сами дистрибутивы собираются из некоторого  проверенного рабочего состояния pN, далее ветки pN служат для  обновления официальных дистрибутивов.  У официального дистрибутива есть ответственный, он решает, что и как  попадает в ветку pN. По-видимому, при этом предполагается, что перед  попаданием новых пакетов в ветку их работа _где-то_ _как-то_  тестируется ответственным - т.е. pN - это предполагающиеся стабильными ветки. Также, наверно, предполагается, что внутри ветки pN не собирающихся на её базе пакетов нет. Отсюда - предполагается достаточно консервативный подход к обновлению  версий пакетов ради новых версий, с отдачей приоритета совместимости работы фиксированного набора пакетов и беспроблемностью установки обновлений по сравнению со свежестью версий. (Ещё большая консервативность и стабильность до замшелости и  неработоспособности на современном железе - это ветка c6.) Sisyphus - это нестабильный репозиторий, что и как в нём обновляется и добавляется - зависит от желаний участников проекта. Развал части  системы или системы целиком при обновлении до текущего состояния  Sisyphus - вполне возможен. tN - база для выпуска неофициальных дистрибутивов и репозиторий для  обновления тех, кому хочется более свежего ПО по сравнению с pN, но меньше потенциальных проблем с совместимостью, чем в Sisyphus. Соответственно, решение об обновлении пакетов в tN лежит на участниках проекта, ответственность за работу и предварительное тестирование на  совместимость - на них же. И, отсюда же - предполагаемая квалификация пользователей веток, от начинающих и/или не готовых возиться с совместимостью ПО для  официальных дистрибутивов до готовых и умеющих решать проблемы самостоятельно для Sisyphus. И, по-видимому, предполагаемый объём  этой пользовательской базы - от широких масс у официальных  дистрибутивов до достаточно узкого круга пользователей Sisyphus. Т.е., при получении неудовлетворительного результата после запуска apt-get update && apt-get -y dist-upgrade : - пользователь Sisyphus рассмотрит это как возможность в очередной раз    проверить актуальность имеющихся у него процедур восстановления   системы из актуальной резервной копии, - пользователь tN - будет вспоминать, как восстанавливать систему из   резервной копии, - пользователь pN - будет вспоминать, есть ли у него вообще резервные    копии. Соответственно, и различающийся подход для обновления версий ПО в репозиториях. Как пример: обновить Apache до 2.4 в Sisyphus -  замечательно. То, что при этом меняется mod_rpaf на mod_remoteip после  обновления надо править руками конфигурацию, и заодно теряется  возможность запуска  httpd2 в  контейнерах OpenVZ - это издержки  Sisyphus и это нормально. В tN (если такое обновление версии решит устроить майнтейнер пакета) - то при установке нового Apache надо бы уже предусматривать автоматическое переделывание  конфигурации  rpaf.{conf,load} -> remoteip.{conf,load}, или хотя бы класть в пакет шаблоны remoteip.{conf,load}. И далее разбираться с невозможностью  запуска под OpenVZ, уже после попадания пакета в ветку и появлением  жалоб. А для конкретной ветки pN такое обновление версии пакета, по-видимому,  уже делать нельзя - и это должно блокироваться ответственным за  ветку pN. Исходя из всего этого - логичнее всего была бы схема движения пакетов  unstable (Sisyphus) -> staging (tN) -> stable (pN) (и это вроде бы  изначально предполагалось по названиям релизов пакетов и пути  обновления между репозиториями pN -> tN -> Sisyphus). По факту оно не сложилось, и окончательно закрепилось политикой  создания t7 через полгода после p7.  Если сейчас не будет t8 - ну, значит, часть пользователей t7 уйдёт  на p8, часть - переберётся на Sisyphus, часть уйдёт на другие дистрибутивы. В итоге это скорее приведёт к некому числу дополнительно выявленных (возможно, и исправленных) багов в t8, и снижением числа  продвинутых пользователей проекта в целом. Будут ли при этом активнее обновляться пакеты в p8 - вопрос сложный. Если и будут - то ценой снижения стабильности самого p8. Плюс, скорее всего появятся отдельные репозитории с локально собранными новыми версиями пакетов на кодовой базе p8 - по аналогии с имеющимся для, скажем, того же CentOS. В отсутствии "карманов", обсуждаемых  с начала десятилетия - локального же качества и локального же тестирования. Т.е.: отказаться от t8 можно, и посмотреть, к чему в итоге приведёт  такой эксперимент. Если бы ветки делались раз в год - было бы совсем не страшно. При текущем цикле в 2-3 года - надо будет смотреть, куда будут уходить продвинутые пользователи с плавно протухающего по  версиям p8 - на нестабильный Sisyphus, или другие дистрибутивы.  Ещё один вариант - перейти к годовому циклу выпуска (квази)стабильных  веток. Т.е., делать t8 не сейчас, а весной 2017 г. Сейчас тогда с t7 желающие более-менее свежих версий и некоторой стабильности переходят  на p8, с более-менее свежим ПО, далее через полгода - на появившийся  t8, в 2018г - на p9 (а при его отсутствии - на новый t8.1), и т.д. -- С уважением, Николай Фетисов