Видели новый apt?

Так что бардак и превращение системы в слаку — это исключительно заслуга ваша и алгоритмов apt-а.

Ты отчасти прав, но как это противоречит тем сообщениям, на которые ты фейспалмы поставил?

Мне вот лень перебирать эти простыни на предмет нужно/не нужно, вот они и копятся. Иногда что-то почищаю оттуда (расставляют «установлено вручную» на нужное или удаляю ненужные), но иногда. Автоудалить всё - заведомо знаю что что-то мне сломает. Т.к. среди таких повисших зависимостей могут быть нужные проги или библиотеки с которыми уже что-то скомпилено.

У apt тут даже известно в чём недостаток: он при удалении мастер-пакета молча оставляет его зависимости в виде «установлено автоматически, но уже не нужно» и не имеет нормального структурированного описания текущей ситуации.

Как можно было бы сделать хорошо: при удалении пакета, если у него есть автоустановленные зависимости, прям в том же листинге действий писать «эти пакеты теперь (т.е. раньше не висели) повиснут в неопределённом статусе». И, возможно, иметь какой-то простой способ сразу же вручную разрешить эту ситуацию: указать, какие их них удалить вместе с мастер-пакетом, а какие перевести в статус установленных вручную.

Ну и при выводе простыни «авто ненужных» не писать их сех в одну строчку, а тоже показывать кто кого тянет. Например, если пакет A зависит от пакетов B и C, пакет B зависит от B1, C зависит от C1 и C2, и все эти пакеты не установлены вручную, то показывать надо по дефолту только A, а остальные - только указывать «а также ещё 5 зависимостей могут повиснуть», либо выводить их если указано какое-нить --verbose. Тогда вместо необъятных простыней будет чёткое понимание реального списка пакетов, про которые надо что-то решить.

это ещё фигня, вот как в zypper-е в русской локали:

Выберите по номеру одно из указанных выше решений или пропустите, повторите попытку или отмените [1/2/п/е/о/д/?] (о):

система в русской локали - по идее все должно на русском быть

а ты в фб консоли, где переключалка на русский не настроена

и попытка авторемува всегда приводили к проблемам

всегда удаляю только так # apt --purge autoremove имя_пакета и ни разу проблем не возникло

где переключалка на русский не настроена

настроена - только не понятно зечем… что можно писать по русски в ядерной консоли?

Так юникод же

В Дебьяне с нуля установленная система УЖЕ имеет ненужные пакеты. После доустановки нужного, количество «ненужных» возросло.

Крутая система. Восхищение. xD

Как можно было бы сделать хорошо: при удалении пакета, если у него есть автоустановленные зависимости, прям в том же листинге действий писать «эти пакеты теперь (т.е. раньше не висели) повиснут в неопределённом статусе». И, возможно, иметь какой-то простой способ сразу же вручную разрешить эту ситуацию: указать, какие их них удалить вместе с мастер-пакетом, а какие перевести в статус установленных вручную.

Поздравляю, вы изобрели pacman.

Вот скажи – ты всё это описываешь, а самому вообще приятно запинаться об эти грабли?

Если это домашняя система, а не решение для организации, то в чем высший смысл специально страдать?

Все мои страдания с Дебианом закончились, когда я 14 лет назад установил Арч.

По прошествии времени могу сказать, что это решающее облегчение в плане понятности и управляемости системы. Сэкономленные нервы означают, что я просто пользуюсь компьютером в своё удовольствие, а не пытаюсь решать проблемы, которые без компьютера бы даже не возникли.

К сожалению,мне не встречалось хорошего учебника по управлению пакетами.

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

Зато Дебиан нас может порадовать огромными мануалами по операциям, необходимым для пакетирования программы, которые действия в других пакетных системах вообще не существуют. Вроде компьютер нужен для автоматизации, а тут наоборот: человек выполняет механические действия ВМЕСТО машины.

А что ему тогда делать за компом если не месить пакетную глину?
Ты ему предлагаешь что-то реально полезное что ли делать?
Офигел?

Если это домашняя система, а не решение для организации, то в чем высший смысл специально страдать?

Я не страдаю,а наслаждаюсь. Линукс - это моя любимая компьютерная игрушка. Играю с 1997 года и по сей день не надоело. И копаясь во внутренностях системы регулярно узнаю что-нибудь новое так как эти внутренности периодически меняют чтобы жизнь таким как я не казалась скучной. А раньше когда работал - за умение играть в линукс еще и деньги неплохо платили потому что хороших «игроков» в те времена мало было. Это сейчас куда ни плюнь - в линуксоида попадешь. И умения типа способности исправить неработающий драйвер какой-нибудь железки уже ценности не представляют,не говоря уже о просто настройке линуксового софта.

Все мои страдания с Дебианом закончились, когда я 14 лет назад установил Арч.

Когда я 27 лет назад поставил Дебиан - Арча просто еще небыло. А Дебиан выбрал потому что в нем было больше всего готового к употреблению софта. Так что буду продолжать играть в Дебиан пока он поддерживает 32-битные системы(i686 и ARMv7). Дальше будем посмотреть на что переходить. Наверно на Альт,у него точно еще долго поддержка 32bit будет. Кстати,у Альта пакетный менеджер интересно сделан - используется apt-get,но при этом сами пакеты в формате rpm,а не deb. Не знаю почему так.

Зато Дебиан нас может порадовать огромными мануалами по операциям, необходимым для пакетирования программы, которые действия в других пакетных системах вообще не существуют.

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

К сожалению,мне не встречалось хорошего учебника по управлению пакетами.

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

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

Отдельно отмечу,что я никого не агитирую ставить именно Дебиан,просто рассказываю о своем «исторически сложившемся» опыте.

Да я тоже никого не агитирую, но при воспоминаниях о Дебиане у меня периодически пригорает. Личная травма =)

И как же там пакеты делают без мануалов?

https://wiki.archlinux.org/title/Category:Package_development

Тут всё описано языком для людей.

А теперь для сравнения откроем что-нибудь про Дебиан. Например вот здесь: https://www.debian.org/doc/manuals/maint-guide/first.ru.html#workflow

Целиком цитировать не буду, т.к. на форум не удобно форматирование вставлять, но достаточно прочитать параграф 2.1, который начинается словами «При создании пакета Debian из исходного кода программы в процессе сборки на каждом этапе генерируется несколько файлов со специальными именами: <…>»

А если читать следующие параграфы, ситуация становится всё хуже.

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

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

Это потому, что Дебиан – огромная бюрократическая шарага, которая не имеет целью, чтобы ПОЛЬЗОВАТЕЛЬ (не являющийся членом шараги) что-то мог легко в Дебиан добавить.

При наличии общих скиллов работы с UNIX-like системами сборка пакета состоит из двух достаточно тривиальных операций:

• Описать машине, как надо собирать пакет.
• Запустить процесс сборки.

Ворох бесполезного барахла, не имеющего отношения к делу, для этого не нужен.

В разработке ПО, да и не только ПО, есть две опасности, которые подстерегают разработчика:

• Использование низкоуровневых абстракций создаёт много ручной работы и порождает ошибки.
• Использование высокоуровневых абстракций создаёт необходимость подчиняться искусственным правилам, но всё равно не избавляет от ошибок на низком уровне, потому что абстракции протекают.

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

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

Примеры пакетных систем, где пакетирование ПО достаточно тривиально для продвинутого пользователя:

• Arch
• Alpine
• Gentoo
• Void
• pkgsrc

Это потому, что Дебиан – огромная бюрократическая шарага, которая не имеет целью, чтобы ПОЛЬЗОВАТЕЛЬ (не являющийся членом шараги) что-то мог легко в Дебиан добавить.

Это безусловно так. Но это относится не только к Дебиану. Добавить что-нибудь в ядро или например в Иксы - также невозможно если не «член шараги».

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

Хотите добавить что-то в дистрибутив - договаривайтесь с российскими дистростроителями,с тем же Альтом. Они вполне договороспособны. Никто не мешает нам всем собрать такое же крупное сообщество вокруг отечественного дистрибутива и проводить удобную нам политику. Сейчас еще и шанс договориться о взаимодействии с госорганами есть. В отличие кстати от Дебиана который «ихним» госорганам безразличен.

Описать машине, как надо собирать пакет. Запустить процесс сборки. Ворох бесполезного барахла, не имеющего отношения к делу, для этого не нужен.

При взгляде со стороны далеко не очевидно что есть «бесполезное барахло»,а что имеет отношение к делу. Я вовсе не утверждаю что дебиановская система пакетирования идеальна - я для этого недостаточно хорошо представляю себе все возможные случаи ее использования. Среди них есть такие,с которыми мне за 27 лет пользования Дебианом так и не приходилось сталкиваться. Но это не значит что они не нужны тем кто их применяет. И вполне может быть что кажущееся избыточно усложненным для масштабов небольшого офиса - вполне разумно выглядит в организациях где используются сотни компьютеров и все их надо обслуживать и сопровождать.

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

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

Зачастую в винды добавить «что-то» если не проще, то уж точно фановее. Примеры:

• Да что вы знаете о некромантии
• https://github.com/Skulltrail192/One-Core-API-Binaries

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

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

В этом смысле Дебиан соответствует букве СПО, но не соответствует духу.

Была для старых виндов такая программа Talisman Desktop (может и для новых есть, не интересовался), которая заменяла собой в реестре explorer.exe в качестве запускаемой при логине оболочки рабочего стола.

Она позволяла «мышкой напрограммировать» себе любой рабочий стол с любыми мыслимыми виджетами.

По возможностям кастомизации внешнего вида наверно до сих пор обгоняет Плазму. А работала на таких компах, в которых по современным меркам «вообще нет ОЗУ».

Другой пример – некоторые аудиоплееры, почти бесконечно расширяемые через систему плагинов как во внешнем виде, так и в новых функциях.

Еще один пример – Total Commander, для которого написана просто чёртова уйма плагинов, начиная от работы со всеми мыслимыми форматами архивов и образов и заканчивая плагинами для просмотра 3D-моделей.

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

Лично мне доставляет намного больше фана собирать конструктор NetBSD, в котором по умолчанию даже никаких конфигов для shell не настроено, чем пытаться на личной машине бороться с тем, как в Дебиане «люди сделали свой дистрибутив и рулят в нём так как им удобно».

Continue? [Д/н]

Вот это действительно «красота».

Еще один пример – Total Commander, для которого написана просто чёртова уйма плагинов Это всё примеры проприетарных решений, которые однако ориентированы на то, чтобы продать пользователю конструктор, а не прибитое гвоздями решение.

Вообще-то если говорить именно о плагинах то в линуксе есть немало софта,который может подключать плагины которые пользователь просто положил в своем домашнем каталоге вообще без всякого пакетирования. В качестве примеров audacity,kicad,gimp (это из того чем сам часто пользуюсь и поэтому вспомнил).

Лично мне доставляет намного больше фана собирать конструктор NetBSD

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

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

Вообще-то если говорить именно о правке,а не пакетировании «с нуля» то я бы не сказал что в дебиане это сложно если знаешь как либо имеешь перед глазами описание процесса. Некоторые трудности могут возникать только в тех пакетах где управление патчами теперь сделано через quilt. Штука это весьма неудобная и капризная,требует очень точного соблюдения «магических ритуалов» чтобы сделала именно то что надо. Всё время пытается «левые» патчи выкинуть. Но она применяется в достаточно небольшом числе пакетов,которые редко когда пересборки требуют (в Иксах например). И формально говоря quilt это не часть системы пакетирования, это отдельный [неудобный] инструмент. Причем в большинстве руководств по [пере]сборке пакетов он не описан. Из тех немногочисленных описаний где он есть - мне нравится это: https://raphaelhertzog.com/debian-packaging/

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

Вообще-то если говорить именно о плагинах то в линуксе есть немало софта,который может подключать плагины которые пользователь просто положил в своем домашнем каталоге вообще без всякого пакетирования. В качестве примеров audacity,kicad,gimp (это из того чем сам часто пользуюсь и поэтому вспомнил).

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

В gimp-е, чтобы написать простой плагин, нужно знать основы лиспа, который туда встроен, и почитать про API, доступное плагину. Тут нет избыточной сложности за пределами той, что требует задача объективно.

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

Тут есть объективная сложность, а есть сложность из воздуха.

Составные части объективной сложности:

• Программа может иметь неочевидные привязки к аппаратной архитектуре (они могли быть даже для автора не очевидны).
• Может быть нетривиальна работа с кроссплатформенным тулингом.
• Могут быть пропущенные зависимости пакета. Решается проверкой в чруте.

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

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

Не надо изобретать сложности там, где их нет.

В gimp-е, чтобы написать простой плагин, нужно знать основы лиспа, который туда встроен

Можно и на Питоне,который куда более понятен обычному человеку чем Лисп.

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

В большинстве случаев в Дебиане скомпилировать в хомяк можно и запустить из хомяка можно. Ну кроме каких-то совсем уж системных компонентов типа Х-сервера - с ним наверно так не получится. В смысле - запустить.

В Арче ничего сверх этой сложности нет.

В Дебиане я тоже не вижу каких-то сложностей если ограничиться «несистемным» софтом и своей машиной(или даже небольшим офисом на несколько компов). Что будет на огромных масштабах - сказать затрудняюсь,просто небыло случая попытаться. А себе я например уже много версий дебиана (лет так двадцать+) пересобираю XLib с нужным мне патчем для поддержки кодировки CP866 - и трудностей не испытывал пока в этот пакет всё тот же quilt не внедрили. Вот тогда повозиться пришлось,но тоже справился. Теперь там не просто положить патч в нужный подкаталог с патчами надо,а еще и «зарегистрировать» его в quilt,иначе выкинет. Вот уж действительно кто-то из хозяев дебиана мелкую гадость сделал. Причем у меня не хватает мозгов чтобы понять его логику - зачем.