Проблема с установкой/удалением virtual box

Удаляй посредством apt.

apt-get remove virtualbox

или

sudo apt-get remove virtualbox

Пробовал. Вот что на выводе:

SyntaxError: invalid syntax
dpkg: error processing package virtualbox (--remove):
 subprocess installed pre-removal script returned error exit status 1
Traceback (most recent call last):
  File "/usr/bin/pycompile", line 35, in <module>
    from debpython.version import SUPPORTED, debsorted, vrepr, \
  File "/usr/share/python/debpython/version.py", line 24, in <module>
    from ConfigParser import SafeConfigParser
ImportError: No module named 'ConfigParser'
dpkg: error while cleaning up:
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 virtualbox
E: Sub-process /usr/bin/dpkg returned an error code (1)

если питон2, то pip install ConfigParser, если питон3, то pip install configparser

после этого снова удаляйте вбокс

subprocess installed post-installation script returned error exit status 1

Казалось бы, какое отношение послеустановочные скрипты имеют к удалению пакета?

Вообще, у Дебиана сказочный пакетный менеджер. Я только в Дебиане видел, чтобы ПМ валился с ошибками при переустановке или удалении криво установленного пакета.

Блин. Теперь и pip ставиться не хочет

Exception:
Traceback (most recent call last):
  File "/tmp/tmp8qargni3/pip.zip/pip/basecommand.py", line 215, in main
    status = self.run(options, args)
  File "/tmp/tmp8qargni3/pip.zip/pip/commands/install.py", line 342, in run
    prefix=options.prefix_path,
  File "/tmp/tmp8qargni3/pip.zip/pip/req/req_set.py", line 784, in install
    **kwargs
  File "/tmp/tmp8qargni3/pip.zip/pip/req/req_install.py", line 851, in install
    self.move_wheel_files(self.source_dir, root=root, prefix=prefix)
  File "/tmp/tmp8qargni3/pip.zip/pip/req/req_install.py", line 1064, in move_wheel_files
    isolated=self.isolated,
  File "/tmp/tmp8qargni3/pip.zip/pip/wheel.py", line 345, in move_wheel_files
    clobber(source, lib_dir, True)
  File "/tmp/tmp8qargni3/pip.zip/pip/wheel.py", line 316, in clobber
    ensure_dir(destdir)
  File "/tmp/tmp8qargni3/pip.zip/pip/utils/__init__.py", line 83, in ensure_dir
    os.makedirs(path)
  File "/usr/lib/python3.5/os.py", line 241, in makedirs
    mkdir(name, mode)
PermissionError: [Errno 13] Отказано в доступе: '/usr/local/lib/python3.5/dist-packages/pip'

валился с ошибками

А должен героически все разломать до конца и отрапортовать об успехе, ага.

Другие пакетные менеджеры не валятся, а этому сраному танцору постустановочные скрипты мешают, лол.

Ну а что ему делать, если он по определению не имеет интерактивного режима?

При чём тут интерактивный режим?

В общем, накатил pip, вывод такой же как и в прошлый раз.

Щииииит!1 После накатывания pip, ещё и apt отвалился.

А что должен делать пакетный менеджер при критической ошибке? Волшебным образом устранить проблему?

Таких ошибок вообще быть не должно, лол.

ошибок вообще быть не должно

Все претензии к сторонним репозиториям.

Да не, это apt - кривая говнина.

А что не говно? Может есть такое, где нет ошибок, ничего не сегфолтится, и при этом это не страна выдуманных розовых единорогов.

У pacman нет таких даунских глюков

У пакмана нет сторонних бинарных реп, одна аур-помойка, которая его не касается напрямую.

У пакмана нет сторонних бинарных реп

И это прекрасно.

Может есть такое, где нет ошибок, ничего не сегфолтится, и при этом это не страна выдуманных розовых единорогов.

Slackware с его pkgtools, slackpkg, slackpkg+.

По-твоему, неработающий послеустановочный скрипт должен блокировать работу ПМ целиком?

Да. Должен отвалиться и ждать ручного вмешательства (интерактивный может сразу ждать команду на починку, но апт не интерактивный). Или отказ от сломанного пакета или починка.

«Помойка в слаке начинается с /»

Тогда самая прекрасная система — это огороженная с прибитым единственным доверенным источником по.

Обоснуй.

Легко: у нас не интерактивный АПТ, он не принимает команды, только простые вопросы. Именно из-за этого в своё время был написан аптитуде.

Пакет сломан. Что делать, если не завершаться с ошибкой? Закончить установку и сообщить: «я тут сломанный пакет поставил»? Не блокировать со сломанным пакетом базу и ждать наслоения на ошибку, когда простое исправление будет уже не возможно?

Да

Ясно. Приятного аппетита, что тут ещё скажешь.

Разруха в головах, да, тогда и помойка от корня.
И Slackware тут совсем не при чем.

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

Ни кто не мешает и в дебиане обходить ПМ, но зачем? У слаки иная философия, и если в голове порядок у пользователя, то он и в слаке не будет срач разводить.

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

У меня проблем как раз минимум, я не знаю как люди умудряются себе приключения с апт наживать. Может просто опыт позволяет не делать глупости (прав Патрек, зная дебиан знаешь только дебиан).

Именно так. Рад, что согласны. Хотя бы с этим ^)

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

Нет, «сломанный пакет» и «завершившийся с ошибкой послеустановочный скрипт» - это совершенно не одно и то же. Зависимости удовлетворены, файлы распакованы, но скрипт завершился с ошибкой. Почему это должно полностью блокировать работу ПМ?

В итоге оказалось что процессор не может в виртуализацию, мда.