LINUX.ORG.RU

В дистрибутивах с ограниченными встроенными средствами установки пакетов (например, Slackware, LFS) используете ли вы какой-либо дополнительный механизм установки ПО?

 , ,


0

1

Уточнение: опрос не затрагивает дистрибутивы вроде Arch, Gentoo и их деривативов, где есть встроенные инструменты, как ebuild/PKGBUILD/Makefile в port tree. Интересуюсь как с недавнего времени пользователь Slackware в качестве основной системы.

  1. не использую такие дистрибутивы203 (71%)

    ********************************************************************************************************************************************************************************************************************************************************************************************************************************

  2. ручная сборка/установка из исходников (./configure ... && make install/uninstall и др.)54 (19%)

    *************************************************************************************

  3. нативные и "полунативные" инструменты (например, slackpkg и Slackbuild-ы/sbopkg)32 (11%)

    **************************************************

  4. Flatpak, AppImage и аналоги с монтированием образа29 (10%)

    *********************************************

  5. rpm, dpkg, инструменты конвертации18 (6%)

    ****************************

  6. другое (в комментариях)12 (4%)

    ******************

  7. pkg-src, Homebrew3 (1%)

    ****

Всего голосов: 351, всего проголосовавших: 286

>>> Проголосовать

★★★

Проверено: hobbit ()

Интересно было бы узнать мнение других, поскольку начал пользоваться Slackware после длительного опыта с FreeBSD/OpenBSD/macOS за прошедшие годы.

У меня как-то так сейчас: по возможности slackpkg, правда, обычно, сразу перехожу к следующему пункту за неимением пакетов, затем Слакбилды, затем make install в /usr/local или еще лучше куда-нибудь поглубже (например, mysql по умолчанию ставится в prefix /usr/local/mysql), с обязательным сохранением исходников в ~/src, чтобы можно было сделать make uninstall.

В качестве редкого исключения rpm (меня несколько удивило, что он в Slackware есть из коробки), это очень удобно - например, таким образом заинсталлил с –nodeps Cloudflare VPN, который только в deb и rpm виде существует, без дженериков в сжатом tar.

Пробую смотреть в сторону pkg-src (было достаточно опыта с ним в SmartOS (форк OpenSolaris от Joyent) и NetBSD).

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

Хм. То что Slackware src-based для меня неожиданно.

Ну а как бы ты ее классифицировал?) Я в некотором смысле это написал из опыта использования. Ну, в смысле, достаточно распространены на том же Reddit r/slackware темы о том, как бы внедрить какую-то «систему портов» и так далее.

И опыт использования опять же туда толкает :) И это не в обиду Slackware, скорее, здорово, что в ней это все органичнее получается (даже простой make install аккуратно, в нужный –prefix при configure), чем в дистрибутивах, построенных на dnf/yum/apt/pacman.

В этом смысле Slackware, как мне кажется по опять же опыту пользования, это аналог LFS.

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

Ну уж ни как сурце базед. Если брать с таким натягом тогда уж лучше АРЧ с АУР.

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

Про «сборку из исходников без пакетов, configure, make install» - это понятно. А вот при чём тут autotools, configure.ac, Makefile.am? Эти штуки тут совершенно сбоку, они никак не связаны ни с наличием пакетов, ни с их отсутствием.

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

А вот при чём тут autotools, configure.ac, Makefile.am? Эти штуки тут совершенно сбоку, они никак не связаны ни с наличием пакетов, ни с их отсутствием.

Спасибо, понял о чем ты. Попробовал переформулировать вариант.

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

Хм. То что Slackware src-based для меня неожиданно.

Понимаю, вообще, о чем ты. Убрал слово «других».

Вообще, идея была исключить те дистрибутивы, в которых собственные встроенные средства сборки есть - PKGBUILD-ы/ebuild-ы/port tree, а задать вопрос о тех дистрибутивах, где встроенных средств не хватает и хочется что-то «навернуть сверху».

Т. е., Arch, Gentoo, деривативы сюда не попадают.

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

Убери из пункта слово autotools вообще, они тут ни при чём. configure и make - это не autotools.

«Запускаю вручную ./configure + make install/uninstall или другие команды ручной сборки/установки» - как то так.

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

А что если не autotools/autoconf,automake генерирует из configure.ac configure и далее Makefile из Makefile.am тогда?

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

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

Вообще, идея была исключить те дистрибутивы, в которых собственные встроенные средства сборки есть - PKGBUILD-ы/ebuild-ы/port tree, а задать вопрос о тех дистрибутивах, где встроенных средств не хватает и хочется что-то «навернуть сверху».

Стоп. Тут какой то разрыв шаблона. В начале про встроенные средства разработки. А не хватает и навернуть сверху это тоже про средства разработки или уже не про них ?

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

Нет это не узкая терминология.

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

./configure это общеупотребительное название скрипта для преднастройки сборщика под конкретную систему.

А вот autotools это всего лишь пакет костылей, который НЕКОТОРЫЕ разработчики используют для генерации configure и Makefile. А некоторые - не используют. Эти костыли совершенно вторичны по отношению к make, появились намного позже и нормальные люди обходятся без них. Генерировать Makefile совсем не обязательно, это формат, который с самого начала был рассчитан на ручное написание. Повторю, тут (в этом выборе) речь не про тебя, который хочет установить прогу, а про её автора.

У некоторых программ сборка может быть вообще без make, можно просто написать шелл-скрипт с вызовом компилятора нужное количество раз. Или например sendmail собирается скриптом на m4, видел какие-то проги, собиравшиеся скриптами на perl-е.

В контексте «какой механизм пакетизации» все эти детали не важны, суть в том что ты скачал официальное дерево исходников и что-то из него запустил чтоб оно скомпилировалось. Но, поскольку обычно это всё-таки configure+make, стоит их упомянуть в пункте ответа, чтобы всем было понятнее о чём речь. А вот разновидности наличия или отсутствия всяческих костылей, которые разработчикам взбрело в голову использовать при подготовка сборочного скрипта своего софта - тут совершенно не важны.

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

Я согласен с тобой, наверное, это специфика моего опыта в разработке - configure и Makefile генерировались чаще autotools. И иногда софт распространяется без готового confugure. Переформулировал :)

Просто мне не казалось это существенным в этом (в)опросе, «узкое» именно в этом смысле использовал.

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

Стоп. Тут какой то разрыв шаблона. В начале про встроенные средства разработки. А не хватает и навернуть сверху это тоже про средства разработки или уже не про них ?

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

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

Ты и макось сюда включаешь? Или Homebrew ещё где-то есть?

Нет-нет, вполне кроссплатформенная же штука. Сам кроме макоси не трогал ее, но:

https://docs.brew.sh/Homebrew-on-Linux

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

@GFORGX, ну подумай тогда ещё, а я следующий по очереди опрос пока подтвержу…

Угу, доформулирую на днях :)

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

Мультивыбор есть, пункт «не использую такие дистрибутивы» (чтоб никто не возмущался) есть. Это главное.

// Шутка.

hobbit ★★★★★ ()

Планирую если не произойдёт ничего чрезвычайного, подтвердить этот опрос следующим, в начале-середине следующей недели.

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

Я бы этот пункт изложил просто как «ручная сборка и установка из исходников».

Автотулзы, как и cmake или мезон — это сборочные системы. Костыли это или нет или уж тем более «нормальные люди» пользуются ими или нет (фи таким быть) — вопрос отдельный и к обсуждаемой теме прямого отношения не имеет.

Основной вопрос темы — это применяют ли пользователи slackware и lfs какие-то средства упорядочивания/автоматизации пакетов или просто руками собрали исходники из ванильной репы и сделали make install (и сборочная система в последнем случае будет, скорее всего та, которую выбрал автор конкретной программы, религиозные споры про autotools/cmake/голый make тут роли не играют).

Ещё уберу слова «только» и «помимо/вместо», в опросе есть мультивыбор, а если все вариации «помимо/вместо» учитывать, то их побольше будет, чем текущих вариантов опроса.

hobbit ★★★★★ ()
Последнее исправление: hobbit (всего исправлений: 1 )

И ещё вопрос: чем те же slackpkg и Slackbuild-ы в слаквари менее родные, чем, скажем, pacman в арчеподобных? Я слаку плохо знаю, к сожалению.

hobbit ★★★★★ ()
Последнее исправление: hobbit (всего исправлений: 1 )

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

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

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

flatpak не является mounted image. он использует ostree вместо этого.

eternal_sorrow ★★★★★ ()

Я обычно делаю так:
1. создаю у себя в /home точку монтирования для псевдодиска или живого диска точку INSTALL.
2. Беру свежие сырцы и устанавливаю при помощи makepkg или slacktrack проги не входящие в дистрибутив туда. Получается что-то вроде виндового Program Files
3. Прописываю пасы до INSTALL/Program/bin
В саму систему устанавливаю только программы имеющиеся в оф репе.
4. Коммерческое ПО, иногда ставлю в /opt

splinter ★★★★★ ()

Во-первых не использую, во-вторых просто закидываю в /opt уже собранные – Telegram Desktop, musikcube, micro, pwsh. Телега обновляется сама, pwsh и musikcube сообщают о новой версии, micro выходит редко (2.0.11 через год после 2.0.10).

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

библиотеки для чего? туда прописываются только библиотеки взаимодействующие с бинарями в системе. если пакет А установленный в INSTALL зависит от библиотеки B, то просто используем LD_PRELOAD_PATH, можно в корень INSTALL вписать соответсвующий скрипт, который инициализировать в .bashrc при логине. Но это какой-то странный вариант, который я никогда не использовал.

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

Ну приложение же как правило свои библиотеки ставит, в твоем случае они пойдут в INSTALL/Program насколько я понимаю. Как оно у тебя их подхватывает?

James_Holden ★★ ()

хм, а есть вообще дистрибутивы без пакетного менеджера кроме уже упомянутых slackware и LFS (хотя это и не дистрибутив в привычном понимании)? К примеру я сделал себе отдельный раздел Applications куда кладу AppImage файлы ¯_(ツ)_/¯

Не совсем конечно хорошее решение, поэтому хочу портировать из helloSystem систему открытия .app файлов. По сути как на маке - директория с бинарником и либами внутри. Никаких монтирований, песочниц, fuse и т.д.

Было бы круто для dolphin написать плагин чтобы он автоматом запускал .app и отображал иконки. Но у меня руки пока не доходят, да и начать с чего я пока не знаю. Возможно стоит поковырять аналогичный плагин для поддержки AppImage.

Unixson ()
Последнее исправление: Unixson (всего исправлений: 1 )

Боже упаси такое говно использовать.

slovazap ★★★★★ ()

Slackware. Собираю в lxc с чистой rootfs, устанавливаю там же с помощью slacktrack, на выходе получаю tgz, который устанавливаю installpkg на хосте. Всё чётко и прозрачно - всегда можно сделать полный uninstall, даже если система сборки это не поддерживает, не опасаясь, что какой-то мусор останется.

x-signal ★★ ()

Чем бы дети ни тешились, лишь бы не руками.

pr849 ()

nix можно на любой дистр поставить же. Правда не факт, что установленные таким способом программы будут хорошо работать, но всё же. При этом это не будет инструментом конвертации, и не будет полунативным способом. Должен быть отдельный пункт (поздно, да?).

По теме — не пользуюсь такими дистрибутивами, но на других дистрибутивах использую flatpak.

Aceler ★★★★★ ()

все устанавливаю в $HOME/.local используя просто make install(другие варианты) или в бинарном виде. /opt /usr/opt /usr/local неиспользую.

nionio35 ()
Последнее исправление: nionio35 (всего исправлений: 1 )

Не использую. Секса много, польза неочевидна.

Долго сидел на слаке, собирал чего не хватало через ./configure, make, make install

yu-boot ★★★ ()

не использую такие дистрибутивы [✔]

Но когда использую (точнее «использовал»  — в основном в «образовательных» целях), то

ручная сборка/установка из исходников (./configure … && make install/uninstall и др.) [✔]

CrX ()

не пользуюсь такими дистрибутивами

По возможности.

другое (в комментариях)

Бывает, что использую докер для этих целей.

PS: а что, сегодня кто-то ещё пользуется слакой?

Harliff ★★★★★ ()
Последнее исправление: Harliff (всего исправлений: 2 )

Ручная сборка, установка в директорию под управлением GNU Stow.

stargrave ()

Было дело, прикручивал opkg к моему старинному японскому NAS’у.

eugrus ★★★★ ()

pkg-src, Homebrew1 (1%)

Вот и выяснилось реальное количество маководов на ЛОРе.

А то верещали все, как это круто - мак. И всё такое.

Поржал.

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

Вообще тут гораздо чаще попадаются топики о том, что Windows круче Linux в 100500 раз, а не Mac.

А вот Windows в вариантах выбора как раз и нет.

emorozov ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)