EY>>> поставить и потом обновить не предлагать) >> >> это в общем-то единственный нормальный путь. Ядро зависимостей имеет >> нуль, поэтому поставить ядро из squeeze труда большого не >> представляет, при этом squeeze имеет сильно меньше проблем чем >> backports, поскольку фиксится быстрее. YK> После того как backports стала официальным, разве это время не одинаково? суть в том что в бакпортс попадает не по определенным правилам (как в тестинг например) а чисто вручную. То есть попросили майнтенера его пакет собрать в backports, или просто майнтенер считает что его надо собрать для backports, то пакет в backports попадет. Нет желания/времени у майнтенера этим заниматься - пакета в backports не будет. Я немножко наблюдаю за backports там типичные ситуации такие: 1. часто очень в backports собирает пакет не майнтенер пакета (поскольку майнтенерам backports относительно похрену) 2. в backports часто пакеты попадают с бааальшими лагами (то есть если в тестинге побывало 20 версий, то в backports может побывать одна) кроме всего прочего каждый аплоад в backports проверяется человеками примерно так же как каждый *новый* пакет в Debian/sid. То есть иногда скапливается очередь по причине банального человеческого фактора, что тоже не приводит к быстрому обновлению backports. в итоге серьезные пакеты (такие в которых бывают уязвимости, например) брать из backports зачастую более опасно, чем брать из testing. Ну а если говорить о ядре, у которого зависимостей то почти и нет, то тут вообще однозначно тестинг рулит :) -- ... mpd playing: U.D.O. - Animal House . ''`. Dmitry E. Oboukhov : :’ : email: unera@debian.org jabber://UNera@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
Attachment:
signature.asc
Description: Digital signature