Sid в Stable

[Galaxy]

Здравствуйте. В порядке бреда. Если в source.list изменить sid на testing, то когда-нибудь система станет testing? И после заморозки testing и релиза системы, у меня будет stable?
Ну то есть версии пакетов в testing когда-нибудь же будут выше, чем в unstable? И заменят их?
Надеюсь, я понятно объяснил, что хотел спросить? =)

[SLEDopit]

Если в source.list изменить sid на testing, то когда-нибудь система станет testing?

да.

И после заморозки testing и релиза системы, у меня будет stable?

если вы будете продолжать обновляться и после официального релиза, то нет.
а если вы в день релиза смените testing на stable в sources.list, то да.

Ну то есть версии пакетов в testing когда-нибудь же будут выше, чем в unstable? И заменят их?

да.

Надеюсь, я понятно объяснил, что хотел спросить? =)

да (:

[Galaxy]

И после заморозки testing и релиза системы, у меня будет stable?

если вы будете продолжать обновляться и после официального релиза, то нет.
а если вы в день релиза смените testing на stable в sources.list, то да.

Точнее не скажешь =) Прямо мою мысль озвучили.

Спасибо за ответы.

[t.t]

Теоретически да. Практически попадаются пакеты, которые болтаются в unstable очень долго или даже всегда.

[Galaxy]

Практически попадают ся пакеты, которые болтаются в unstable очень долго или даже всегда.

И чем это чревато? Моя задумка не осуществится?
Уважаемый t.t, не могли бы Вы рассказать, вообще можно как-то даунгрейд Debian сделать? Потому что всё, что я прочитал по этому поводу, кажется мне каким-то неточным.
Я знаю, что официально такая возможность не предусмотрена, но хочется услышать Ваше мнение.

[t.t]

Даунгрейд — довольно сложная процедура. Такой «ползущий даунгрейд», как Вы описали, куда проще. Я говорил в первую очередь о таких пакетах, которых вообще нет в teiting, но они есть в unstable (или нет в stable, но есть в testing). В этом случае пакет может в более стабильную ветку не попасть очень долго или вообще никогда. Соответственно, при «ползущем даунгрейде» такие пакеты (а возможно, и некоторые их зависимости) так и останутся из менее стабильной ветки. Впрочем, если эта ветка будет отключена, они будут отображаться как «устаревшие» и их, соответственно, легко будет вычистить.

[Galaxy]

Благодарю за ответ.

[watashiwa_daredeska]

И после заморозки testing и релиза системы, у меня будет stable?

если вы будете продолжать обновляться и после официального релиза, то нет.
а если вы в день релиза смените testing на stable в sources.list, то да.

Можно просто прописать по имени грядущего релиза. Т.е. если прям сейчас, то wheezy. Тогда оно сейчас будет testing, а когда придет время, заморозится и станет stable.

[t.t]

Даунгрейд — довольно сложная процедура. Такой «ползущий даунгрейд», как Вы описали, куда проще.

И кстати, в случае «ползущего» перехода с unstable через texting на stable вскоре после релиза как раз самое подходящее время его начать.

[t.t]

Да, ещё есть вероятность, что установленные из unstable версии некоторых пакетов так и не успеют доползти до testing к следующему релизу. Здесь я уже говорю о тех пакетах, которые в testing есть, но более старые. В этом случае их вычистить вот так одним махом не получится. Придётся либо искать с помощью apt-cache policy или apt-versions (кажется, так), либо жить с ними до ещё более следующего релиза.

[Galaxy]

Даунгрейд — довольно сложная процедура. Такой «ползущий даунгрейд», как Вы описали, куда проще.

И кстати, в случае «ползущего» перехода с unstable через texting на stable вскоре после релиза как раз самое подходящее время его начать.

Почему? Потому что так быстрее закончится процесс?

[t.t]

Даунгрейд — довольно сложная процедура. Такой «ползущий даунгрейд», как Вы описали, куда проще.

И кстати, в случае «ползущего» перехода с unstable через texting на stable вскоре после релиза как раз самое подходящее время его начать.

Почему? Потому что так быстрее закончится процесс?

Скорее он будет более цельным. Смотрите: идеальный момент начала - день релиза. В этот день testing и unstable одинаковые. Если перейти с unstable на testing в этот день, переход начнётся и закончится редактированием sources.list: с этого момента Вы уже будете на чистом testing. И второй этап, со следующим релизом, пройдёт столь же естественно: тогда тоже весь testing станет новым stable. Т.е. в этом предельном случае как такового «перехода» не будет вообще, скорее «переключение» — в одно нажатие и даже не прикасаясь к пакетной базе.

Второй предельный случай — переход в момент заморозки. В это время (между заморозкой и релизом) разница между testing и unstable максимальна, но новые пакеты не будут «вползать» в систему в принципе, т.к. обе эти ветки во время заморозки не меняются (новые версии добавляются в experimental).

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

[SLEDopit]

либо жить с ними до ещё более следующего релиза.

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

[Galaxy]

На что только не пойдёшь, лишь бы систему не переустанавливать ...

[t.t]

либо жить с ними до ещё более следующего релиза.

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

Почему же? После первого же релиза в системе из unstable ничего не останется. Т.е. только до него придётся дотянуть без обновлений безопасности, но тут уже никуда не денешься без принудительного даунгрейда: система ведь и есть unstable.

На что только не пойдёшь, лишь бы систему не переустанавливать ...

А это да, переустанавливать — последнее дело. (;