Как там слака поживает?

# apt install -f
И где обещанная магия?

А что, в системе после ваших примеров поломанные зависимости ? Ха, оказывается вы не в курсе про -f. Учите матчасть

-f, --fix-broken Fix; attempt to correct a system with broken dependencies in place. This option, when used with install/remove, can omit any packages to permit APT to deduce a likely solution. If packages are specified, these have to completely correct the problem. The option is sometimes necessary when running APT for the first time; APT itself does not allow broken package dependencies to exist on a system. It is possible that a system's dependency structure can be so corrupt as to require manual intervention (which usually means using dpkg --remove to eliminate some of the offending packages). Use of this option together with -m may produce an error in some situations.

Эта команда используется если юзер сдуру вынес каким то образом один из пакетов linux-image-4.4.0-112-generic linux-image-extra-4.4.0-112-generic. Вот тогда в системе поломанные зависимости и ее применяют. А ваш пример не в тему. Совсем не в тему.

Бред какой-то. Такая ситуация и возникнуть не может ибо в синаптике vmlinuz юзеру никак не встретится.

https://imgur.com/a/dLfic
Странные у вас какие-то утверждения, что не пойдешь проверять, все мимо...

Эта команда используется если юзер сдуру вынес каким то образом один из пакетов linux-image-4.4.0-112-generic linux-image-extra-4.4.0-112-generic. Вот тогда в системе поломанные зависимости и ее применяют. А ваш пример не в тему. Совсем не в тему.

Хорошо, выяснили, apt умеет ломать систему удалением ядра без хваленых предупреждений.
При установленном linux-image и отсутствующем linux-image-extra

# apt install -f
...
обновлено 0, установлено 0 новых пакетов, для удаления отмечено 0 пакетов, и 0 пакетов не обновлено.

Ха, оказывается вы не в курсе про -f. Учите матчасть

Зачем? Я уже давно выучил, забыл и снова вспомнил тут по случаю. Вижу же, что сказки рассказываете, даже чуть сомневаться не начал, неужели склероз мне изменяет.
Ан нет, натурный эксперимент тут же всё расставил по своим местам.

Просто печатаю команду переезда на новый выпуск и лайкаю котиков ещё несколько лет. Спасибо тебе хороший Человек Патрек!

Я не знаю, зачем ты пишешь этот бред мне, но, так и быть, отвечу. Во-первых, это не Debian. Во-вторых, от ядра ничего не зависит, чтобы его удаление что-то сломало. В-третьих, -f исправляет проблемы, к коим отсутствие ядра никак не относится.

Удалил по глупости ведро — поставь обратно, делов-то.

Ты не поверишь, но во многих системах ядро не нужно совсем.

Как и везде:

apt --reinstall install linux-image-чего-нибудь

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

Эта команда используется если юзер сдуру вынес каким то образом один из пакетов linux-image-4.4.0-112-generic linux-image-extra-4.4.0-112-generic. Вот тогда в системе поломанные зависимости и ее применяют.

Почему они поломанные? В нормальных дистрибутивах от ядра ничего не зависит.

Зачем ... мне?

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

Повнимательнее.
Так (позвать apt) можно было бы сделать ДО перезагрузки. Однако перезагрузка не прошла дальше GRUB, который не смог загрузить отсутствующее ядро.
Набирать предложенное в GRUB — сущий бред.
Очевидно, чтобы получить возможность выполнить apt на незагружаемой системе, необходимы дополнительные действия. Какие по-вашему?

Не нравятся эти два тривиальных примера, давайте другой рассмотрим, формулируйте условия (впрочем повторяюсь).

Повнимательнее.

Это ты себе скажи.

Так (позвать apt) можно было бы сделать ДО перезагрузки

Внезапно, в Slackware это тоже лучше делать до. Без ядра вообще неудобно бывает.

Набирать предложенное в GRUB — сущий бред.

Вы с Lowes не родственники? Тоже любитель додумывать за собеседника.

Очевидно, чтобы получить возможность выполнить apt на незагружаемой системе, необходимы дополнительные действия. Какие по-вашему?

Обычно я запускаю систему со съёмного накопителя, если нет более удобных способов.

давайте другой рассмотрим

Ну хз, давай посмотрим. Я вообще не в курсе, что именно вы тут обсуждали, просто поправил ТС.

Внезапно, в Slackware это тоже лучше делать до. Без ядра вообще неудобно бывает.

Лучше. Но можно и после. LILO он такой ;) Я же специально привожу конкретные действия, у них вполне конкретные последствия. Если сразу их рассказывать, интриги не получится, а без нее не интересно. Действия для незнакомого со Slackware и имеющих другие привычки выглядят весьма опасно, но в силу особенностей Slackware такими являются только отчасти. Это же забавно, когда на молоке обжегшись, на воду дуют.

LILO он такой

А, я и забыл. Но это такое, может и не загрузиться (SSD или виртуальный диск с discard, например). К тому же пример с huge-smp, а ваш Патрик рекомендует использовать нормальное ядро с модулями.

Но это такое, может и не загрузиться (SSD или виртуальный диск с discard, например).

Может, знаю, кто-бы сомневался. Тогда штатный вариант восстановления через установочный носитель (тут все как обычно) с флешки или с HDD, или по PXE (тут тоже есть мелкие хитрости).

huge-smp vs. generic-smp

Для приведенного примера — без разницы, специально указал, что это то самое ядро, с которым грузимся. Можно изменить пример для kernel-generic, не поменяется ничего. Или считайте, что это Salix :), там нет kernel-generic.

evilface мне кажется тебе не нужна Слака. А вот тем, кто по-настоящему хочет пользоватся этим дистрибутивом эта ветка обсуждения будет весьма полезной и информативной.

Для меня Слака хороша тем, что изнутри она просто устроена. Сижу на разрабатываемой ветке т.н. Current после очередного обновления осенью прошлого года система буквально распалась на куски, и не загружалась даже. Паниковать не стал, загрузился через флешку. Своими руками востановил систему. Самое трудный этап ремонта наступил тогда, когда пришлось перебирать требуемые модули ядра, найти среди них нужный, и выйти в Сеть. Оказалось, что моё устройство требует для работы аж 3 или 4 разных модуля. Когда Слака несломанная, то модули сами автоматически подгружаются, и на эти дела как-то внимания человек не обращает.

Недавно весь Слакварский Мир облетела новость Эрик сделал «Живой диск». Вот, это было событие! Так вот, я без загрузки с живого диска по крохам своими руками собрал систему. Никогда не забуду этот свой опыт!

Тем слакварщикам, кто сидит на разрабатываемой ветке скажу. Ребята 2017 год пришёлся неровным, согласитесь. А уж когда Патрик загрузил набор обновлений с ядром 4.9-x вот это была встряска, а!

Набор абстрактных рассуждений.

Ну так KISS сам по себе абстрактный принцип. Но из самой формулировки ясно, что чем больше степеней свободы ¯— тем меньше KISS.

То есть, примеров опять не будет...

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

P.S. Ну и для ясности — в KISS нет ничего хорошего. Просто практика, иногда работает, гораздо чаще нет. Наряду с unixway это практики, мёртвые уже десятилетия, и вполне заслуженно мёртвые.

Вообще-то усложнения - это архитектурные усложнения. Чем больше задач решает инструмент - тем он сложнее.

А надо так - один инструмент (пакетный менеджер) проводит операции с пакетами, а другой инструмент - отслеживает зависимости. И вот этот другой инструмент никто никому не запрещает взять и написать. То, что такого отдельного инструмента до сих пор нет, является следствием того, что отслеживать зависимости никому не нужно.

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

То, что такого отдельного инструмента до сих пор нет, является следствием того, что

...кто-то просто не знает о его (на самом деле их) существовании.

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

На самом деле тьма их, от slapt-get до sbbdep, hoorex сотоварищи. Вон, например, Salix взял в качестве основного ПМ slapt-get/slapt-src, дополнил метаинформацию репозитория сведениями о зависимостях.
Но Патрик этот подход не возьмет, потому как это только вершина айсберга, ведь чтобы это нормально заработало, нужно порезать пакеты на лапшу в стиле Debian: -lib, -dev, -doc, ..., иначе по

# slapt-get nmap

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

Существование разных slapt-get'ов, sbbdep'ов,... и т.д. никто не отрицает.

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

Тут главный инженерный вопрос: что заплатим vs. что получим.
Пакетная система в Slackware — tar+сценарий на bash — затрат минимум, пользы вагон.
Давал бы вариант "./configure && make && make install" такие же возможности — стал бы кто заморачиваться с пакетами. Однако не дает, заморачиваются; выходит, профит есть ^)

libsolv

которые кроме решения зависимостей ничего не решают

sbbdep из их числа, просто ведет базу в sqlite и опрашивает ее, ни больше, ни меньше ^) Хотя да, не решает ничего, только ответы выдает на вопросы.

А, ну да.

Тебе про Ерему, а ты про Фом. Изначльно была речь о поломке системы из-за неудовлетворенных зависимостей по причине удаления таковых. В Слаке это делается на раз-два. В deb-base это практически невозможно, и даже когда происходит это легко исправить. А ты начал нести какую-то фантастическую пургу про удаление ядра и восстановление системы после этого. Ну все, ты победил. Если ты настолько идиот, что умудрился удалить последнее рабочее ядро в системе, то действительно, слака рулит. Но во всех остальных куда более часто встречающихся случаях слака сосет с причмокиванием почти у любого существующего дистрибутива.

Пример, сестра, все остальное — разговоры в пользу бедных. Хочется с переходом на личности сказать «слив защитан», но подождем пока.

Изначльно была речь о поломке системы из-за неудовлетворенных зависимостей по причине удаления таковых. В Слаке это делается на раз-два.

Некорректное утверждение вытекающее от неверного восприятия действительноси.

Случаи когда, «программа, которой ты пользуешся не запускается, потому-что ты 3 дня назад удалил, такой-то пакет бывают очень редко. На такую ситуацию может вляпаться разве что человек интересующийся т.н. концепцией „сверхчистой“ Слаки. Слакварщики знаю о чём идёт речь. Да, и в этом конкретном случае, проблем никаких нет, поскольку удалённый пакет обратно загружается и устанавливается. А вот программы взятые из сторонних хранилищ я собирал сам, и знаю, что и как, от чего может зависеть.

На практике, случаев когда, „я вот over 9000 пакетов из сторонних хранилищ поустанавливал , и чтобы не забыть, отчего что зависит, запишу-ка я теперь всё себе на бумажку и приклею на стене“, не бывает. Если и бывают, то очень редко. Slackware целостный дистрибутив, там есть всё на все случаи жизни. А случаев типа: „Ах! у Патрика есть этот пакет, а я вот привык пользоватся другим“ чисто теоретически конечно могут быть.

Цитата из книги Герарда Бикманса „Linux с нуля“.

6.3.2.1. Всё у меня в памяти!
Да, это метод управления пакетами. Некоторым специалистам менеджер пакетов не нужен, поскольку они хорошо знакомы с пакетами и знают, какие файлы устанавливает каждый пакет. Некоторым пользователям также не нужно никаких менеджеров пакетов, поскольку они планируют пересобрать всю систему, когда пакет изменится.

На самом деле тьма их, от slapt-get до sbbdep, hoorex сотоварищи.

Вот и осветили бы в вики все это оптом по спецзаявкам телезрителей. Почему нет ? А потом отсылали бы всех праздношатающихся, заинтересованных, прочих колеблющихся по ссылке читать.

приедет бабушка python с Иксами,

Не, лучше сразу 4 гига хлама установить.

Куча бесполезной работы чтобы что? Чтобы получить еще один Debian? ^)

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

з.ы. Давно пора создать новую модификацию на базе слаки. А ретрорады пускай юзают ваниль.

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

з.ы. Давно пора создать новую модификацию на базе слаки. А ретрорады пускай юзают ваниль.

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

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

Удалять можно. Но, надо понимать что делаешь.

Некоторые, например, после дистрибутивов, где всё покрошено на мелкие пакетики, даже не задумываются о том, что в Слаке большие пакеты. Без отдельных -dev пакетов. А пакеты программ могут содержать и *.so файлы.

А потом, конечно, «Слака виновата».

Значит так и запишем. Слака это такой дистрибутив, который должен быть установлен целиком — для начинающих. И, если что-то удалять, то с осторожностью, и помаленьку, при прекрасно осозновая последствия своих действий. Все эти манипуляции Патриком не возбраняется. Прям настоящий UNIX для джедаев.

Я твой блокнотик подправил. Не благодари.

з.ы. Давно пора создать новую модификацию на базе слаки.

Ты был в заморозке. Они уже есть и их немало. Иди в Википедию и найди шаблон где указаны дистры основанные на Слаке. SUSE прям настолько глубоко модифицировалась, что похожа стала на Rad Hat.

А ретрорады пускай юзают ваниль.

Дурачок, хе-хе-хе. Эти так называемые тобой «ретрограды» юзают чистейшей воды UNIX-like. И им хорошо!