LINUX.ORG.RU
решено ФорумAdmin

«aptitude upgrade» погрязла в конфликтах.

 , , ,


0

1

Aptitude тужиться и выдает примерно такую строчку которая бесконечно меняется:

open: 37067; closed: 68995; defer: 68; conflict: 103

Я хотел бы найти источники конфликтов и разрешить их. Дело в том, что я по незнанию соединил unstable, testing и stable в своем source.list, теперь хочу исправить ситуацию перейдия полностью на testing. Собственно у меня в source.list теперь только testing. Осталось сделать апгрейд, и именно с этим у меня проблема. FAQsFromDebianUsers советует мне использовать apt-show-versions чтобы посмотреть с какой ветки какие программы, но проблема в том, что чтобы его установить synaptic требует удалить кучу другого софта. Например, требуется безвозвратно удалить ни в чем не повинный glogic.

Что мне делать? Переустанавливать с нуля очень не хочу.

Deleted

Последнее исправление: Deleted (всего исправлений: 3)

А некоторые всё еще ругают Ubuntu Snappy и предрекают провал...

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от redgremlin

Типа этого, да. Однако, это не единственный баг на эту тему. Вообще, перечитайте сообщение по ссылке, что я кидал выше, после первого спойлера. Там и пример есть, который у меня воспроизводится. И ссылки.

Я сам от этого бага пострадал, после чего прекратил пользоваться aptitude. Пробую иногда, как там у неё дела, и каждый раз удаётся воспроизвести этот баг. А учитывая темп разработки и сходящееся к нулю число обратных зависимостей, вероятность исправления, к сожалению, низка. Не зря для всех операций с пакетами рекомендуется apt-get.

anonymous
()
Ответ на: комментарий от Deleted

Нет, aptitude богаче функционалом, не спорю (хотя аналога apt-cache policy, apt-get changelog ..., apt-get install localfile.deb (в sid) же нет?). Лично для меня в ней 3 проблемы: тормоза, неадекватный решатель и баг с автоматически установленными пакетами. Причём если первые два ещё можно как-то терпеть, то последний критичен.

anonymous
()
Ответ на: комментарий от Deleted

Вы не поняли суть примера, и поэтому воспроизводите неправильно. (Вообще, воспроизводить надо в точности, а не в своей интерпретации.)

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

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

anonymous
()
Ответ на: комментарий от anonymous

сколько прибыло - столько убыло.
правда, забавный факт остаётся:
после удаления пакета xfwm4:

 > aptitude show libxres1                                                                                          [0]
Package: libxres1                        
State: installed
Automatically installed: no
.......
что, однако, не помешало всё вычистить команде aptitude -f install. хм.. не могли бы вы тоже воспроизвести проблему?

Deleted
()
Ответ на: комментарий от Deleted

Всё совсем не так хорошо, как вы думаете.

TLDR: ещё разок установить и удалить - и aptitude окончательно забывает об оставленных пакетах.

В общем, вы поймали баг: флаг автоматической установки был снят. И хотя где-то у aptitude осталась информация об этих пакетах, это было ненадолго. В результате получили мусор в системе.

anonymous
()
Ответ на: комментарий от anonymous

В общем, вы поймали баг: флаг автоматической установки был снят. И хотя где-то у aptitude осталась информация об этих пакетах, это было ненадолго. В результате получили мусор в системе.

была догадка, что aptitude держит эти пакеты, так как они рекомендованы каким - то уже установленным другим.
Действительно, aptitude why сообщал о рекомендациях касательно оставленных пакетов.
Проверил устанавливая kwin (зависимостей там много), принудительно отключив рекомендации:

Apt "";
Apt::Install-Recommends "false";
Apt::AutoRemove "";
Apt::AutoRemove::RecommendsImportant "false";
Apt::AutoRemove::SuggestsImportant "false";
подобное поведение более не проявлялось. все установленные зависимости удаляются с первого захода. можете попробовать, к примеру, на виртуалке.

Deleted
()
Ответ на: комментарий от Deleted

Такое «решение» меня не устроит.

  1. Это всё равно не избавляет от бага, а только лишь снижает вероятность его проявления. Скажем, нижеследующая последовательность действий опять приводит к тому, что об установленных по зависимостям пакетах забывается.
    # aptitude install xfwm4
    # dpkg -r xfwm4
      или
    # apt(-get) remove xfwm4
      или
    удаление xfwm4 в synaptic/apper/gpackagekit/whatever...
    # aptitude install xfwm4
    Всё, ни aptitude remove xfwm4 ни последующее выполнение aptitude -f install не приводят к удалению более не нужных пакетов.

    Вместо удаления xfwm4 могло быть обновление, меняющее список зависимостей, средствами apt (в том числе использующих его unattended-upgrades, cron-apt, tasksel и т. д.), synaptic, интерфейсов к packagekit...

    В любом случае флаг автоматической установки не должен убираться без причины.

  2. Даже если пакеты удерживались через рекомендуемые, это не объясняет, почему aptitude их забыла после повторной установки исходного пакета. Ведь это действие ничего не меняет в данных зависимостях, поэтому aptitude должна либо не обращать внимания на эти зависимости, либо обращать, но главное - стабильно, а не «сегодня помню, завтра не помню».
  3. Если я захочу установить пакет с включёнными рекомендациями: aptitude -r ... - то aptitude захочет вынести только что установленные рекомендованные пакеты при следующем же install.
  4. Лично я не отключаю установку рекомендованных пакетов по умолчанию, ибо по моему опыту гораздо проще пробежаться по списку устанавливаемого, чтобы изредка выкинуть что-то явно ненужное, нежели каждый раз выискивать среди рекомендуемых полезные и нужные пакеты.
anonymous
()
Ответ на: комментарий от anonymous

провёл серию экспериментов.
действительно, если, к примеру удалить через dpkg, то удалённый пакет aptitude метит как 'pi', т.е размечает под удаление. с другой стороны в системе его больше нет. И в части случаев aptitude забывает про существование его зависимостей. В любых других ситуациях баг не проявляется. Попробую поиграться с другими пакетниками, посмотрим как они реагируют на подобное.

Deleted
()
Ответ на: комментарий от Deleted

В любых других ситуациях баг не проявляется

Отнюдь. Помнится, вы говорили о том, как хороша aptitude при необходимости downgrade. Рассмотрим stable с подключённым testing. Естественно, stable выбран веткой по умолчанию, ибо мы не хотим превратить всю систему в testing. Подопытным пакетом выберем hugin, ибо его версия в testing уже не зависит от некоторых пакетов, от которых зависит версия в stable - довольно типичная ситуация. Приступим:

  1. Ставим hugin из stable: aptitude install hugin.
  2. Обновляем hugin из testing с помощью, например, synaptic, или же apt: apt -t testing install hugin.
  3. Делаем downgrade: aptitude install hugin/stable.

Всё, при последующих обновлениях hugin более не нужные зависимости удалены не будут.

С apt, как я ни извращался, подобного достичь не удалось. Работает железобетонно. (А в особо запущенных случаях поломок зависимостей всегда помогала грамотная расстановка приоритетов репозиториев.)

anonymous
()
Ответ на: комментарий от Deleted

Всё же интересно, каков масштаб проблемы у вас. Что выведет, скажем, aptitude search '~i!~M~n^lib!~prequired!~pimportant!~pstandard'?

anonymous
()
Ответ на: комментарий от anonymous

Всё же интересно, каков масштаб проблемы у вас. Что выведет, скажем, aptitude search '~i!~M~n^lib!~prequired!~pimportant!~pstandard'?

прошу:

 > aptitude search '~i!~M~n^lib!~prequired!~pimportant!~pstandard'                                                 [0]
i   libegl1-mesa-drivers                                - free implementation of the EGL API -- hardware drivers       
i   libgl1-mesa-dri                                     - free implementation of the OpenGL API -- DRI modules         
i   libglw1-mesa                                        - GL widget library for Athena and Motif -- runtime            
i   libgnome-2-0                                        - The GNOME library - runtime files                            
i   libgnome2-0                                         - The GNOME library - transition package                       
i   libgnome2-bin                                       - The GNOME library - binary files                             
i   libgnome2-common                                    - The GNOME library - common files                             
i   libgnomevfs2-0                                      - GNOME Virtual File System (runtime libraries)                
i   libgnomevfs2-common                                 - GNOME Virtual File System (common files)                     
i   libnotify-bin                                       - sends desktop notifications to a notification daemon (Utiliti
i   libopenvg1-mesa                                     - free implementation of the OpenVG API -- runtime             
i   libosmesa6                                          - Mesa Off-screen rendering extension                          
i   libreoffice                                         - office productivity suite (metapackage)                      
i   libreoffice-calc                                    - office productivity suite -- spreadsheet                     
i   libreoffice-style-sifr                              - office productivity suite -- Sifr symbol style               
i   libreoffice-writer                                  - office productivity suite -- word processor                  
i   libwayland-egl1-mesa                                - implementation of the Wayland EGL platform -- runtime 
гномовские либы тянула celestia. меса поставлена ручками, как и либрофис. либнотифай тоже.

Обновляем hugin из testing с помощью, например, synaptic, или же apt: apt -t testing install hugin.

Ещё раз подтверждается необходимое условие для появления проблемы: пользоваться несколькими пакетниками одновременно, что, кстати, не рекомендуется в принципе.

Deleted
()
Ответ на: комментарий от Deleted

меса поставлена ручками

Что, прям все 6 пакетов, явным образом указывались после install?

Сколько лет этой системе?

Ещё раз подтверждается необходимое условие для появления проблемы: пользоваться несколькими пакетниками одновременно, что, кстати, не рекомендуется в принципе.

Это где вы такую глупость прочитали? Все менеджеры пакетов используют общую базу. Если нужно сохранить какую-то дополнительную информацию, это делается отдельно для каждого менеджера в его собственном месте. Если какой-то из менеджеров портит общую базу, это баг.

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

Ну и, наконец, когда меня задел этот баг, я пользовался исключительно aptitude. Так что я абсолютно уверен, что можно смоделировать ситуацию, когда неиспользование других менеджеров не спасёт, ибо проблема-то не в них, и портят базу вовсе не они. Если будет время, попробую тщательнее поискать такие случаи.

anonymous
()
Ответ на: комментарий от anonymous

Что, прям все 6 пакетов, явным образом указывались после install?

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

Сколько лет этой системе?

достаточно много, так как апдейтилась ещё со сквези.

Это где вы такую глупость прочитали? Все менеджеры пакетов используют общую базу. Если нужно сохранить какую-то дополнительную информацию, это делается отдельно для каждого менеджера в его собственном месте. Если какой-то из менеджеров портит общую базу, это баг.

Всё верно. Но всё же лучше кучей пакетников одновременно не пользоваться. Где рекомендацию видел - не вспомню, давно было.

Если будет время, попробую тщательнее поискать такие случаи.

Буду благодарен, интересно.

Deleted
()
Ответ на: комментарий от anonymous

Всё же интересно, каков масштаб проблемы у вас. Что выведет, скажем, aptitude search '~i!~M~n^lib!~prequired!~pimportant!~pstandard'?

рабочий пк, системе больше года, но софта на нём установлено куда больше (рабочий же).

 > aptitude search '~i!~M~n^lib!~prequired!~pimportant!~pstandard'                                                
i   libegl1-mesa-drivers                                - free implementation of the EGL API -- hardware drivers       
i   libgl1-mesa-dri                                     - free implementation of the OpenGL API -- DRI modules         
i   libglw1-mesa                                        - GL widget library for Athena and Motif -- runtime            
i   libgnomevfs2-extra                                  - GNOME Virtual File System (extra modules)                    
i   libjson-perl                                        - module for manipulating JSON-formatted data                  
i   libnotify-bin                                       - sends desktop notifications to a notification daemon (Utiliti
i   libopenvg1-mesa                                     - free implementation of the OpenVG API -- runtime             
i   libosmesa6                                          - Mesa Off-screen rendering extension                          
i   libreoffice-calc                                    - office productivity suite -- spreadsheet                     
i   libreoffice-impress                                 - office productivity suite -- presentation                    
i   libreoffice-style-sifr                              - office productivity suite -- Sifr symbol style               
i   libreoffice-writer                                  - office productivity suite -- word processor                  
i   librsvg2-bin                                        - command-line and graphical viewers for SVG files  
вижу 2 лишние либы: librsvg2-bin и libgnomevfs2-extra.

Deleted
()
Ответ на: комментарий от Deleted

Я тут вспомнил, что в Debian важные системные файлы периодически сохраняются в /var/backups/, в том числе и база расширенных состояний apt /var/lib/apt/extended_states, где и хранится информация о том, какие пакеты устанавливались автоматически. Можно сравнить текущее содержимое этой базы с сохранёнными ранее резервными копиями на предмет пропавших записей.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.