LINUX.ORG.RU

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

 , ,


1

1

Разработчиками Arch Linux объявлено о прекращении поддержки ABS.

Пакет extra/abs уже удалён из репозитория, а rsync.archlinux.org/abs закроют в конце этого месяца.

В качестве причины отказа от ABS названы излишние затраты на поддержку.

Вместо ABS теперь следует использовать extra/asp.

>>> Подробности

Ответ на: комментарий от complamer

apt install — 11
pacman -Syu — 11

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

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

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

mandala ★★★★ ()
Последнее исправление: mandala (всего исправлений: 2)
Ответ на: комментарий от anonymous

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

bodqhrohro_promo ()

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

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

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

intelfx ★★★★★ ()
Ответ на: комментарий от curufinwe

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

mandala ★★★★ ()
Ответ на: комментарий от makoven

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

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

NextGenenration ★★ ()
Ответ на: комментарий от saahriktu

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

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

NextGenenration ★★ ()
Ответ на: комментарий от complamer

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

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

NextGenenration ★★ ()
Ответ на: комментарий от complamer

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

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

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

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

временно

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

saahriktu ★★★★★ ()
Ответ на: комментарий от man_of_motley

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

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

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

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

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

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

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

curufinwe ★★★★★ ()
Ответ на: комментарий от saahriktu

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

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

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

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

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

dpkg -r --force-depends <package>
rpm -e --nodeps <entire-package-name>
(rpm -qa | grep "package")
pacman -Rdd <package>
И т.д.

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

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

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

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

saahriktu ★★★★★ ()
Ответ на: комментарий от Vigi

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

saahriktu ★★★★★ ()
Последнее исправление: saahriktu (всего исправлений: 1)
Ответ на: комментарий от saahriktu

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

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

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

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

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

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

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

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

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

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

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

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

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

mandala ★★★★ ()
Последнее исправление: mandala (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

saahriktu ★★★★★ ()
Ответ на: комментарий от Vigi

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

mandala ★★★★ ()
Ответ на: комментарий от saahriktu

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

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

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

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

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

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

saahriktu ★★★★★ ()
Последнее исправление: saahriktu (всего исправлений: 1)
Ответ на: комментарий от saahriktu

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

Singularity ★★★★★ ()
Ответ на: комментарий от saahriktu

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

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

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

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

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

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

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

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

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

saahriktu ★★★★★ ()
Последнее исправление: saahriktu (всего исправлений: 1)
Ответ на: комментарий от saahriktu

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

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

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

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

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

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

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