Обновление Debian testing (Два маленьких вопроса по xorg и gnome)

[t.t]

ZeBriD, советую изучить хоть немного дебиановскую систему управления пакетами, прежде чем о ней говорить. На практике в рамках одной системы легко уживаются не только testing и unstable, но и к ним до кучи stable с experimental. И насчёт зависимостей вы не правы: в значительной части случаев пакеты из unstable зависят от версий [ >= те что в testing-е ] (или даже в stable); не говоря уже о том, что часто версии в зависимостях и вообще не прописываются. Для примера, у меня сейчас установлена смесь из testing (большей частью), stable и unstable (по мелочи) -- и все зависимости для xorg 7.1.0 и xserver-xorg-core 1.1.1, которые из experimental, на данный момент полностью удовлетворены; т.е. я их легко могу поставить в свою систему, не обновляя кроме них _вообще ничего_.


Mayuka, да, прошу прощения, уже вижу:

Нужен все таки testing но хотелось бы так же иметь новые пакеты из unstable.Как я понял в sources.list надо добавить строку:
APT::Default-Release "testing";
если я хочу использовать все таки по умолчанию ветку testing и затем прописать пути к ветке unstable.
И пакеты соответствено нужные из ветки unstable ставить командой :
apt-get -t unstable install имя_пакета
Правильно я хоть расуждаю или надо как то по другому?

↑

Совершенно правильно рассуждаете, только версия X-сервера, которую вы хотите поставить, находится на данный момент не в unstable, а в experimental.

[ZeBriD]

ZeBriD, советую изучить хоть немного дебиановскую систему управления пакетами, прежде чем о ней говорить. На практике в рамках одной системы легко уживаются не только testing и unstable, но и к ним до кучи stable с experimental. И насчёт зависимостей вы не правы: в значительной части случаев пакеты из unstable зависят от версий [ >= те что в testing-е ] (или даже в stable); не говоря уже о том, что часто версии в зависимостях и вообще не прописываются.

Писал по собственному опыту. У меня стоит смесь из 75% sid и 25% etch. Бывали случаи, когда при установке пакета, он из-за зависимостей не ставился, т.к. версии пакетов требовались выше, чем имелись в репозитарии. А так... я же не говорил, что всё будет валиться по этой причине. Я так же не отрицаю то, что смеси живут и процветают (и я думаю так у большинства и есть). Я просто предупреждал, что такое возможно (уж это то вы не будете опровергать ), чтобы человек не пугался .

[t.t]

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

↑

В случае когда подключены все четыре репозитария (stable, testing, unstable, experimental) и прописан Default-Release я такого не видел никогда, даже при установке пакетов из сторонних репозитариев.

Я просто предупреждал, что такое возможно (уж это то вы не будете опровергать )

↑

Я, собственно, не могу согласиться вот с этими вашими фразами:

Ну для начала определись, что тебе всё же надо: testing или unstable ?

↑

Большинство пакетов из unstable по зависимостям потянут (очень) большое кол-во пакетов из него же

↑

А если надо установить единичный пакет из sid-a, то проще будет воспользоваться #dpkg -i имя_пакета.deb

↑

Конкретно: определяться вовсе ненужно (вы, кстати, и сами сказали, что используете смесь как раз из testing и unstable); большинство пакетов из unstable установятся либо вообще на чистый testing, либо в крайнем случае попросят обновить по одному-два пакета. Исключения, конечно, имеются, но кто-то разве будет удивляться, что, к примеру, kdebase 3.5.4 зависит именно от пакетов из kde 3.5.4, а никак не меньше? Что, однако, вовсе не мешает обновить отдельно почти любое kde-шное приложение, без обновления самого kdebase. А слово "проще", применённое к dpkg -i по сравнению с apt-get install или aptitude install вообще сложно воспринимать всерьёз.

[Mayuka]

ZeBriD, советую изучить хоть немного дебиановскую систему управления пакетами, прежде чем о ней говорить. На практике в рамках одной системы легко уживаются не только testing и unstable, но и к ним до кучи stable с experimental. И насчёт зависимостей вы не правы: в значительной части случаев пакеты из unstable зависят от версий [ >= те что в testing-е ] (или даже в stable); не говоря уже о том, что часто версии в зависимостях и вообще не прописываются.

Писал по собственному опыту. У меня стоит смесь из 75% sid и 25% etch. Бывали случаи, когда при установке пакета, он из-за зависимостей не ставился, т.к. версии пакетов требовались выше, чем имелись в репозитарии. А так... я же не говорил, что всё будет валиться по этой причине. Я так же не отрицаю то, что смеси живут и процветают (и я думаю так у большинства и есть). Я просто предупреждал, что такое возможно (уж это то вы не будете опровергать ), чтобы человек не пугался .

Ну меня в последние время очень сложно напугать (после продолжительного общения с Slackware и FreeBsd). Но Debian мне в последние время все больше и больше начал нравиться со своей зависимостью пакетов

P.S. И еще такой вопрос в чем все таки разница между apt-get и aptitude?И что лучше использовать?

[georgy_sh]

P.S. И еще такой вопрос в чем все таки разница между apt-get и aptitude?И что лучше использовать?

ИМХО, я пользуюсь исключительно apt-get'ом.

А по существу aptitude успешно разрешает конфликты зависимостей, которые apt-get разрешить не может.
Помнится, в Debian - russian прямо обсуждение было - "aptitude vs apt-get". Попробуйте поискать на http://lists.debian.org/debian-russian/

[chitatel]

большинство пакетов из unstable установятся либо вообще на чистый testing, либо в крайнем случае попросят обновить по одному-два пакета. Исключения, конечно, имеются, но кто-то разве будет удивляться, что, к примеру, kdebase 3.5.4 зависит именно от пакетов из kde 3.5.4, а никак не меньше?

Я правильно Вас понял, что это распространяется только на testing/unstable (experimental?), и не распространяется на stable/testing (нынешние Sarge/Etch)?..

Что, однако, вовсе не мешает обновить отдельно почти любое kde-шное приложение, без обновления самого kdebase.

Ибо при попытке поставить что-либо kde'шное из testing в Sarge apt хочет качать кучу объёмом 145Mb.

P.S.

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

↑

В случае когда подключены все четыре репозитария (stable, testing, unstable, experimental) и прописан Default-Release я такого не видел никогда, даже при установке пакетов из сторонних репозитариев.

Я видел такое, если просто скомандовать apt-get install <имя_пакета>. apt жалуется на сломанные пакеты. Если сделать "по инструкции" apt-get -t (testing/unstable etc) install <имя_пакета>, то всё разруливается.

[t.t]

Но Debian мне в последние время все больше и больше начал нравиться со своей зависимостью пакетов

↑

Система управления пакетами в дебиане вообще самая продвинутая; не зря ведь apt портировали и на rpm-пакеты.

P.S. И еще такой вопрос в чем все таки разница между apt-get и aptitude?И что лучше использовать?

↑

Последнее время aptitude является рекомендуемым средством управления пакетами. Разница по сравнению с apt-get видна в первую очередь в более продвинутом разруливании зависимостей; говорят ещё, что существенна разница в командах upgrade и dist-upgrade, но тут сказать ничего не могу, т.к. обновляю всегда только выборочные пакеты. Разница же по сравнению с apt-cache в значительно более продвинутых средствах поиска; и большем количестве информации о пакетах (либо более удобной её подаче, ввиду чего я в выводе apt-cache просто не всё нашёл ).

Я правильно Вас понял, что это распространяется только на testing/unstable (experimental?), и не распространяется на stable/testing (нынешние Sarge/Etch)?..

↑

Утверждать всеобъемлюще не берусь, но я со stable на testing переползал оч-чень постепенно (что с woody на sarge, что с sarge'а на etch), и проблемы на всех этапах если и возникали, то разруливались вручную через aptitude без малейших напрягов.

Я видел такое, если просто скомандовать apt-get install <имя_пакета>. apt жалуется на сломанные пакеты. Если сделать "по инструкции" apt-get -t (testing/unstable etc) install <имя_пакета>, то всё разруливается.

↑

Во-первых, как я говорил, это сильно зависит от соответствия подключённых репозитариев и значения опции Default-Release реальному положению вещей в системе. Конечно, если на "stable с лёгкой примесью testing'а" попробовать установить пакет при прописанных всех четырёх ветках и отсутствии вышеуказаной опции, ничего хорошего может и не получиться, т.к. при её отсутствии по умолчанию тянется самая свежая версия, каковой с большой долей вероятности будет либо experimental, либо unstable. Вероятно, примерно это произошло, раз принудительным указанием ветки проблема разрешилась. Кроме того, в некоторых случаях aptitude справляется с зависимостями лучше, чем apt-get.

[ZeBriD]

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

↑

В случае когда подключены все четыре репозитария (stable, testing, unstable, experimental) и прописан Default-Release я такого не видел никогда, даже при установке пакетов из сторонних репозитариев.

Я видел такое, если просто скомандовать apt-get install <имя_пакета>. apt жалуется на сломанные пакеты. Если сделать "по инструкции" apt-get -t (testing/unstable etc) install <имя_пакета>, то всё разруливается.

Спасибо за поддержку , а то я уж начал думать, что меня скоро начнут судить за клевету <_<

[t.t]

Спасибо за поддержку , а то я уж начал думать, что меня скоро начнут судить за клевету

↑

Никто ни слова не говорил про клевету; говорилось только о корректности/некорректности способов работы с несколькими репозитариями.

[Mayuka]

Спасибо за поддержку , а то я уж начал думать, что меня скоро начнут судить за клевету

↑

Никто ни слова не говорил про клевету; говорилось только о корректности/некорректности способов работы с несколькими репозитариями.

И еще такой вопросик (просто не хочется из за этого заводить новую тему ).Пр выполнении aptitude update началось сыпаться вот такое:
Чтение списков пакетов... Готово
W: Conflicting distribution: http://debian.nsu.ru etch-proposed-updates Release (expected etch-proposed-updates but got testing-proposed-updates)
W: GPG error: http://debian.nsu.ru testing Release: Следующие подписи не могут быть проверены, так как недоступен общий ключ: NO_PUBKEY 07DC563D1F41B907
W: GPG error: http://debian.nsu.ru unstable Release: Следующие подписи не могут быть проверены, так как недоступен общий ключ: NO_PUBKEY 07DC563D1F41B907
W: GPG error: http://debian.nsu.ru sarge Release: Следующие подписи не могут быть проверены, так как недоступен общий ключ: NO_PUBKEY BB5E459A529B8BDA
W: Вы можете запустить 'apt-get update' для исправления этих ошибок

При запуске apt-get update выдает тоже самое. Блин как это лечить уже не знаю в гугле нашел только вот это :
www.nsu.ru/phpBB/viewtopic.php?t=8925& sid=f13989297dc736ae4a80c8e7f19d7c76
Вот так же мой sources.list :
deb cdrom:[Debian GNU/Linux testing _Etch_ - Official Snapshot i386 Binary-1 (20060810)]/ etch maindeb http://debian.nsu.ru/debian/ etch main non-free contrib
deb-src http://debian.nsu.ru/debian/ etch main non-free contrib


deb http://security.debian.org/ etch/updates main contrib non-free
deb-src http://security.debian.org/ etch/updates main contrib non-free


# Proposed updates

deb http://debian.nsu.ru/debian etch-proposed-updates main non-free contrib
deb-src http://debian.nsu.ru/debian etch-proposed-updates main non-free contrib

# MPlayer and related stuff
deb http://debian.nsu.ru/debian-marillat testing main
deb-src http://debian.nsu.ru/debian-marillat unstable main

#Java
deb http://debian.nsu.ru/debian-java sarge non-free
deb-src http://debian.nsu.ru/debian-java sarge non-free

[ZeBriD]

Спасибо за поддержку , а то я уж начал думать, что меня скоро начнут судить за клевету

↑

Никто ни слова не говорил про клевету; говорилось только о корректности/некорректности способов работы с несколькими репозитариями.

И еще такой вопросик (просто не хочется из за этого заводить новую тему ).Пр выполнении aptitude update началось сыпаться вот такое:
........

Попробуй использовать ftp зеркало.

[unix_man]

Однажды запустив
apt-get update
вы вдруг получаете что то типа

....
Чтение списков пакетов... Готово
W: GPG error: http://security.debian.org stable/updates Release: Следующие подписи не могут быть проверены, так как недоступен общий ключ: NO_PUBKEY 010908312D230C5F
W: GPG error: http://ftp.debian.org testing Release: Следующие подписи не могут быть проверены, так как недоступен общий ключ: NO_PUBKEY 010908312D230C5F

Это просто означает что ваш apt обновился до версии, где научился проверять целосность пакетов посредством pgp цифровой подписи.

1) Если вам все равно настоящие пакеты из репозитория или кто то подменил их, то можно отказатся от этой возможности:
apt-get --allow-unauthenticated update

или добавить /etc/apt/apt.conf
APT::Get::AllowUnauthenticated 1;

2) Если идти совсем debian-way то необходимо установить
sudo apt-get install debian-keyring
который установит базу данных цифровых ключай разработчиков debian
а потом с помощью apt-key добавлять нужные ключи

Но. Эта база данных весит 11 мегабайт. Плюс к этому на неофициальных репозиториях этот способ не сработает (например ftp://ftp.nerim.net).

3) можно добавлять ключи самостоятельно (естественно пакет gnupg должен быть установлен)

gpg --recv-keys 010908312D230C5F
gpg --armor --export 010908312D230C5F | sudo apt-key add -