Arch Linux прекращает поддержку ABS

sudo pacman-optimize

не пробовал?

Возможно у меня кривые руки, но на лубунте табом install не дополняется, да и неудобно это, проще pacman -S набрать

man bash-completion
man alias
man ~/.bashrc /root/.bashrc

Использую zsh, читать три мана вместо одного не хочу.

apt install — 11
pacman -Syu — 11

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

Ты хочешь превратить пакетный менеджер в systemd?

Не релевантно. ПМ меняется (пусть вместе с дистром), сустемдик выбрасывается всё сложнее.

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

Хоть бы один рассказал, как это коснётся AUR, который вроде как на ABS основан, если коснётся вообще. Насколько мне известно, переезд на git был при переходе на aur5. При том, abs они дропнули только сейчас?

на всякую фигню

Думаю, ты свое высказывание охарактеризовал как нельзя лучше.

Пасман тоже так может.

Я рассказал. Читай выше. Никак не коснётся.

extra/asp

Что такое extra/asp?

Хорошо, уговорил: в следующий раз позову тебя засвидетельствовать.

Что такое extra/asp?

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

asp

Имя пакета с программой https://github.com/falconindy/asp

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

Я хочу на это посмотреть.

Можно временно вынести любой пакет, даже тот, от которого по факту зависит половина системы. И при этом эта половина системы останется на месте, а не удалится вслед за тем пакетом, от которого она зависит.

Только вот работать не будет.

вместо длинного aptitude install короткий pacman -S

Не осилил алиасы? Что значат однобуквенные ключи без мана не догадаться.

Что должен делать пакетный менеджер, кроме распаковки архивов, учета этих архивов и контроля зависимостей/конфликтов?

pacman научился даунгрейдить пакеты?

Что «работать не будет»? Я же специально написал:

временно

Например, хороший тон сборки пакета с Perl'ом требует чтобы в системе не было уже установленного Perl'а. Тогда можно будет проверить корректность включения модулей в новый пакет. Т.е. удаляется старый пакет, собирается новый пакет, и этот новый пакет устанавливается вместо старого.

Ага, работает, спасибо. Только всё равно уж лучше хранить в дб, являющейся файлом, ИМО. Или использовать VFS, если так хочется работать именно с файлами.

Да. Правда, из локальных копий всё равно надо ручками.

Разве не для этого придумали контейнеры? Ставишь минимальную систему без всяких перлов и риска что-то обрушить.

Да. Правда, из локальных копий всё равно надо ручками.

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

pacman -U - и даунгрейдь что хочешь.

А вообще, «одна команда» - понятие растяжимая. Можно генту установить одной командой, только эта команда будет на полстраницы длиной.

Постинстайн

Пост- и пре- инсталл хуки сойдут? Можно даже свои делать.

Её отсутствие может быть даже плюсом. Легче красноглазить

А если просто нужно поставить работающий софт?

apt install — 11
pacman -Syu — 11

Вот только pacman -Syu делает столько же сколько аж две команды в apt, ты про apt update забыл.

Причём тут контейнеры и минимальные системы? Речь про тот же десктоп с полноценной системой. Вот как на нём, например, собрать свой пакет с Perl'ом чтобы потом заменить этим пакетом бывший до этого в системе? Можно, конечно, не удалять старый пакет и собрать новый пакет при уже установленном Perl'е. Но, повторяю, правила хорошего тона рекомендуют сначала вынести уже установленный пакет с Perl'ом, а уже потом собирать новый пакет. В Slackware это всё by design.

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

dpkg -r --force-depends <package>

rpm -e --nodeps <entire-package-name>
(rpm -qa | grep "package")

pacman -Rdd <package>

А если просто нужно поставить работающий софт?

Когда я юзал Arch и мне нужно было ставить софт из AUR'а, я и там вычислял зависимости вручную, и руками собирал каждый из пакетов. Точно также можно ставить софт со slackbuilds.org или из своих собственных слакбилдов.

Для тех же, кому нужно за 10 минут всё развернуть, в Slackware существует утилита slapt-get, которая умеет разруливать зависимости пакетов, которые не входят в базовую систему.

там вычислял зависимости вручную

Зачем ты это делал, если в aur зависимости прописывают сразу в pkgbuild?

Я не совсем про это написал. Так-то и на slackbuilds.org указывают зависимости. Но, вот, например, прописаны в PKGBUILD'е зависимости, и надо посмотреть какие из них уже есть в системе, а какие - нет. При этом ряд зависимостей также могут быть именно в AUR'е. А у них свои зависимости. Которые также могут быть в AUR'е. А у тех свои... И вот надо это всё распутать и собрать вручную по одному пакету в такой очерёдности, чтобы в первую очередь были установлены те пакеты, которые потребуются следующим пакетам. А если ставить всё подряд без учёта этой очерёдности, то, разумеется, будет ругань на отсутствующие зависимости, и ничего не получится.

Так-то и на slackbuilds.org указывают зависимости.

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

Повторяю: есть slapt-get. Но, если хочется ручного контроля, то альтернатив ручному рассчёту зависимостей нет.

А у них свои зависимости. Которые также могут быть в AUR'е. А у тех свои... И вот надо это всё распутать и собрать вручную по одному пакету в такой очерёдности, чтобы в первую очередь были установлены те пакеты, которые потребуются следующим пакетам. А если ставить всё подряд без учёта этой очерёдности, то, разумеется, будет ругань на отсутствующие зависимости, и ничего не получится.

Добро пожаловать в dependency hell. Для борьбы с этим и придумали appimage, snap, flatpak и другие подобные технологии.

Повторяю: есть slapt-get.

И как он в сравнении с другими пм? Скорость работы, проверка зависимостей, не остается ли мусор после удаления?

Вот пример: на необновленной системе в арче мне надо делать -Syu для корректной установки. В дебиане апт сам подтянет те пакеты которые надо обновить — и только их, а не все, так можно смешивать ветки даже (тестинг и стейбл, например).

И такой ерунды полно. Пакман прост, по этому быстр. АПТ монстр. ДНФ еще монстрее. Но зато фичастые. В пример простоты круче пакмана можно взять Alpine и его apk — он еще проще и быстрее.

И как он в сравнении с другими пм? Скорость работы, проверка зависимостей, не остается ли мусор после удаления?

Не знаю, не юзал.

appimage, snap, flatpak и другие подобные технологии

Спасибо, не надо.

Списки да, можно обновить, особенно на тестинге — но можно не обновлять, если не будет ошибки то всё норм :). Но полностью систему обновлять не обязательно.

Не знаю, не юзал.

Фанатизм как он есть.

Спасибо, не надо.

Мыши плакали кололись...

Спасибо, не надо.

Даже оправдания не будет?

На каком основании? Можно жить даже без пакетных менеджеров вообще. А уж ручное разруливание зависимостей с пакетным менеджером - это вообще курорт. А уж про автоматическое разруливание всех зависимостей из коробки при обширном репозитории (как в том же Debian'е) я вообще молчу (и кому оно нужно те и юзают Debian/Ubuntu/Fedor'у/etc). Ну и зачем все эти новомодные пакеты со всеми зависимостями, когда и так всё работает? Чтобы засорять дисковое пространство тоннами дубликатов одних и тех же библиотек?

Есть же yaourt, который таки умеет в зависимости из AUR'а.

Есть. Но, привычнее и приятнее может быть собирать по пакету руками.

makepkg -d/--nodeps позволяет не проверять зависимости в таком случае.

Можно жить даже без пакетных менеджеров вообще.

Если софтина в одном пакете или требует одного двух для работы и не более того.

Ну и зачем все эти новомодные пакеты со всеми зависимостями, когда и так всё работает?

ПМ что ли просто так придумали?

Чтобы засорять дисковое пространство тоннами дубликатов одних и тех же библиотек?

Ты наверное спутал с шиндовс, да и там эту проблему как-то решили.

Если софтина в одном пакете или требует одного двух для работы и не более того.

Не обязательно. Можно юзать, например, свою сборку на основе LFS'а без пакетного менеджера, постоянно при этом её обновляя. Особенно если эта сборка без иксов и GUI софта. Когда появляются иксы и GUI софт, то тут уже лучше с пакетным менеджером, да.

Особенно если эта сборка без иксов и GUI софта. Когда появляются иксы и GUI софт, то тут уже лучше с пакетным менеджером, да.

Так я же о чем и говорил. А сейчас софт все жирнее и жирнее.

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

вручную вычисляя зависимости и собирая по пакету руками

Но зачем? Луддизм какой-то.

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