Несколько вопросов по Aptitude.

Слишком много вопросов. А были ли попытки читать документацию?

См. документацию aptitude по -F (format). Поля (по памяти): %v - текущая версия, %V - устанавливаемая версия, %p - название пакета(?) и всякие разные другие. Не хочу сейчас смотреть, но думаю, что и репозиторий там имеется. Это форматирование вывода.

Теперь насчет обновляемых пакетов. Делаешь aptitude update, а потом делаешь aptitude search ~U. Тебе выползет список обновляемых пакетов. Формат вывода можешь менять -F.

aptitude -F «%p is upgradable from %v to %V» search ~U

Конкретный репозиторий можешь выбрать при помощи -t

Обновлять пакеты из testing в stable — это моветон. Это дурная практика. Но если ты хочешь что-то обновлять из testing, то пользуйся такой штукой, как apt pinning (man apt_preferences) и дай нужным пакетам нужные приоритеты.

>А были ли попытки читать документацию?

Читал хелп и мануалы. Может быть, плохо читал, но то, что надо - не нашёл.

См. документацию aptitude по -F (format).

Посмотрел. Почти то, что надо. Оно будет в ncurses-режиме работать?

Обновлять пакеты из testing в stable — это моветон.

Не понял фразы. Я живу на тестинге, просто некоторые вещи хочется брать из стейбла.

то пользуйся такой штукой, как apt pinning (man apt_preferences) и дай нужным пакетам нужные приоритеты.

Про apt pinning я читал, но не врубился, как им пользоваться. Наверное, слишком глуп. Сможет ли pinning зафиксировать в одну строчку _все_ пакеты, например, из KDE?

Хорошо, если сможет. Но вопрос-то был, как это сделать в _aptitude_ не отходя от кассы, а не уровнем ниже! Да и зачем тогда хвалёные aptitudовские hold'ы?

>Про apt pinning я читал, но не врубился, как им пользоваться. Наверное, слишком глуп. Сможет ли pinning зафиксировать в одну строчку _все_ пакеты, например, из KDE?

В том виде, в котором он есть в stable, не может. Надо вручную перечислить пакеты в поле Package (это будет адом для KDE, скорее всего). Попробуй придержать только kdelibs5, например. Тогда, может быть, придержится и KDE:

Это в /etc/apt/preferences, потом aptitude update:

Package: kdelibs5 Pin: release o=Debian Pin-Priority: -1

Не понял фразы. Я живу на тестинге, просто некоторые вещи хочется брать из стейбла.

Вообще, при твоем подходе тебе полсистемы придется заморозить. А как ты вообще ставил старый KDE на testing, расскажи? Это специальный форвардпорт для testing или ты из stable ставил? То, что ты задумал — это ад вообще. У тебя конфликт на конфликте будет, если ты заморозишь полсистемы. Прикинь, если старый KDE будет зависеть от системной библиотеки старой версии, а новый софт из testing уже этого не захочет?

Еще идейка (тоже ад). Ты можешь сделать hold для всех пакетов, от которых зависит kde (или какой-там пакет главный?) и только те, которые установлены. То есть что-то типа:

aptitude hold '?reverse-depends(kde)~i'

Лучше сначала погляди на адовый список aptitude search '?reverse-depends(kde)~i' и только потом уже думай и морозь. Обрати внимание на то, что туда куча системных библиотек попадает. Можно еще попробовать ограничить это все только библиотеками, которые только из stable потребовались. Наверное, нужно еще в строчку добавить ~Astable, т. е.

aptitude search '?reverse-depends(kde)~i~Astable'

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

Правильное решение — самое сложное. Это форвардпортить старый KDE в testing. Вообще, сочувствую. :)

Блин, форматирование.

Это в /etc/apt/preferences, потом aptitude update:

Package: kdelibs5
Pin: release o=Debian
Pin-Priority: -1

без cureses - примерно так.
aptitude versions iceweasel
p 3.5.15-1 testing,unstable 500
i 3.6.12-2 experimental 100

Ну еще добавлю, что замораживание прямо всех пакетов (особенно системных библиотек), от которых зависит KDE3, может быть излишним, потому что зависимости могут быть мягкими, то есть в control прописано, что зависит от библиотеки с версией >=1.2, например. Этому условию может удовлетворять библиотека из testing, но работу никто не прогарантирует, если там изменился API. Сопровождающий в данном случае не ограничил сильно зависимость. Автоматически распознать такие случаи — это сложнее. Можно попробовать исключить из списка замораживаемых библиотек testing те, с которыми KDE3 уже уживается, то есть !~Atesting и попробовать составить условие:

~reverse-depends(kde)~i!~Atesting, то есть пакеты, от которых завист kde, которые установлены и которые *не* из testing. Если такх пакетов немного, то их можно не морозить, а просто занести в список в /etc/apt/preferences и поставить приоритет 1001, например. Или крайний случай -1.

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

>А как ты вообще ставил старый KDE на testing, расскажи?

Я его ставил ещё тогда, когда никаких КДЕ4 ещё в проекте не было :).

По поводу того, что приходится замораживать полсистемы - ты прав. С каждым днём со старыми кедами жить всё сложнее. На днях выяснилось, что я не могу обновить apt, так как от него зависит старый konqueror :)

Спасибо за советы, всё попробую. Но кто-нибудь может мне рассказать про п.3? Зачем нужен hold, c чем его едят и как сделать так, чтобы hold не сбрасывался?

А в оболочке?

если бы я ей пользовался, может и сказал бы.

> Содержимое preferences настроено так, что testing считается основным, потом stable, потом unstable и sid.

Отчаянный парень.