LINUX.ORG.RU

какие бывают пакетные менеджеры, предоставляющие выбор из всех опций при сборке?

 , ,


0

1

Какие вообще бывают пакетные менеджеры, которые позвяляют устанавливать из исходников, предоставляя возможность выбора из всех возможных опций компиляции?

Требования:

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


В portrage и paludis есть некоторые недостатки, с точки зрения автоматизма конфигурабельности:
нужно ждать ебилд или самому писать
смириться, что ебилд может быть написан криво
юз-флаги есть не на все опции

★★★★★

лучше портажа нет пока ничего.

В portrage и paludis есть некоторые недостатки, с точки зрения автоматизма конфигурабельности:
нужно ждать ебилд или самому писать
смириться, что ебилд может быть написан криво
юз-флаги есть не на все опции

какое это имеет отношение к тому же портажу? о_О

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

какое это имеет отношение к тому же портажу? о_О

там можно устанавливаить по принципу ./configure "список из всех опций";make;make install? т.е конфигурировать НЕ юз-флагами?

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

не распарсил... вообще можно ебилд запилить и без юзов

.....
econf \
--enable-lol \
... \
--disable-trol

megabaks ★★★★ ()

Не бывает.

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

понятно
а как вообще проверяются зависимости? их создатель ебилда должен в этот самый ебилд вписать?
может есть какие-то более елементарные решения, где просто грепается makefile на зависимости?

а там же в портаже 5 способов установки — есть ещё какие-то атомы и ещё 3 какие-то
можешь в двух словах про эти 4 способа?

teod0r ★★★★★ ()

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

Но все больше понимаю, что это либо будет очередной portage, либо же подобие pacman+AUR.

Конечно, никто не мешает клонировать дерево pkgbuild'ов, дописать туда use'ы, дописать к pacman'у механизм разруливания сборочных флагов. И получится почти что portage, поэтому непонятно, зачем все это делать, разве что будет не на питоне. :)

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

а как вообще проверяются зависимости? их создатель ебилда должен в этот самый ебилд вписать?

аха. иногда зависимости всплывают «ниоткуда» - как таковые в проекте не заданы, но нужны.

может есть какие-то более елементарные решения

не видел таких пока.
про способы не распарсил - атом это категория/пакет или пакет или категория/пакет-версия или пакет-версия
есть ебилды - типа ebuild /path/to/ololo-1.2.3.ebuild X, где X стадия (типа распаковки, компеляния, установки во временную диру или корень и т.д.)
бинарники обычно как атомы ставят - только ключики другие

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

В portrage и paludis есть некоторые недостатки, с точки зрения автоматизма конфигурабельности:

нужно ждать ебилд или самому писать

смириться, что ебилд может быть написан криво

юз-флаги есть не на все опции

где-то это не так?! libastral ещё не осилили, говорят года через 2 в systemd включат.

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

может есть какие-то более елементарные решения, где просто грепается makefile на зависимости?

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

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

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

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

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

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

Прямое.

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

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

но куда тебе понять

Рекордно быстрый слив, чувствуется мастерство.

anonymous ()

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

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

ебилды — зависимость установки от какого-то дяди, заместо того, чтобы просто запустить автоматизированный установщик, который всё возьмёт из мейк файла


но может я просто неосилятор прочтения документации, и portage/paludis всё это умеет?

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

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

интересно, насколько сложно будет написать что-то на shell-script'е, являющееся по сути автоматизатором процесса конфигуре-маке, удовлетворяющее вышеупомянутым требованиям?
проблема в том, что я абсолютный нуб в makefile'ах и процессе компиляции, и мне, так сказать, не до конца видна вся глубина процесса, чтобы оценить сложность предстояшего процесса написания скрипта

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

парсить сорсы.../me прозревает многочасовой расчёт зависимостей при таком раскладе.
это как минимум.
ебилд можно изменить не изменяя его.
s/заместо/вместо/g #реально бесит

megabaks ★★★★ ()

нужно ждать ебилд или самому писать

:) Представьте себе, да, нужно писать самому или ждать, а как по другому-то?

В чём сложность написания ебилда, пусть даже кривоватого и не канонiчного, но работающего?

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

парсить сорсы...

зависимости разве не в makefile, не?

/me прозревает многочасовой расчёт зависимостей при таком раскладе.

а что расчитывать то, если зависимости уже указаны в текстовом файле?

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

ты правда не понимаешь? о_О
ок: есть 1 пакет - парсим сорсы ---> 10 пакетов зависимостей.
распаковываем сорсы 10 пакетов, парсим сорсы ---> ещё по 10 зависимостей у каждого
...
а теперь это всё надо посчитать: убрать дубли, проверить версии, учесть зависимости от выбранных опций...
короче, просто подумай как это должно работать.
для такого подхода нужно не менее 2/4-х ксеонов и десятки гигов как рамы, так и накопителя.
утопия

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

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

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

убрать дубли, проверить версии

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

ок: есть 1 пакет - парсим сорсы ---> 10 пакетов зависимостей.
распаковываем сорсы 10 пакетов, парсим сорсы ---> ещё по 10 зависимостей у каждого

качаем первые 10 пакетов; запускаем сначала установку первого, спрашиваем опции, создаём файл с опциями этого пакета и файл его зависимостей; -> проверяем список установленных и качаем пакеты из списка, которых нет в списке установленных; запускаем установку первого, создаём файлы опций, зависимостей; -> проверяем; переходим ко второму пакету; -> проверяем...
и так для каждого пакета по дереву по очереди. чего считать? после установки каждого пакета обновляется список установленных пакетов, потом перед установкой следущего, этот список просто грепается при проверке наличия в системе нужной зависимости. когда доходит до последней матрёшки в ветке зависимостей, поднимаемся на уровень выше — запускаем install для того пакета, ради которого устанавливалось дерево его зависимостей, пишем его в файл списка установленных в системе пакетов.
зачем десятки гигов рамы?

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

Если считаешь что это настолько просто пиши свой собственный.

init_6 ★★★★★ ()

Ага но особо доставляет:

нужно ждать ебилд или самому писать

да а еще можно нанять кого либо и он напишет за тебя или для тебя

смириться, что ебилд может быть написан криво

ну вообще то кривые ебилды в основное дерево никто не пустит… плюс у генты есть басзилла куда можно слать свои патчи на кривые ebuild-ы

юз-флаги есть не на все опции

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

init_6 ★★★★★ ()

возможно фряшные порты это то, что вы имеете ввиду

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

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

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

прямой. Ты пробовал сделать автоконфигурацию пакетов? более менее адекватные системы сборки есть только у языков с центральным репозиторием, но в них неадекватно указываются зависимости, особенно если они находятся вне домена основного языка. Плюс часть систем используют неявные правила сборки, часть требуют доводки сборки до вменяемого состояния.

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

а кто будет учитывать несовместимость пакетов?

через то же создание файлов с их последующим грепом

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

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

версии, опять же - одному пакету «снизу» плевать на версию либы, а пакету сверху нужна версия ДО какой-то

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

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

Портаж говно не из-за питона, а ибо писан школотой.

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

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

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

Пакетных менеджеров или ebuild-ов не писал, но опыт сборки LFS есть, так что очень хочется разобраться.

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

Тогда интересует ваше мнение о пакетных менеджерах, которые устанавливают каждый пакет(атом, если желаете) в отдельную директорию и ставят symlink в директории /bin, /lib и т.д? Например Nix. Они, вроде, позволяют устанавливать даже разные версии одного и того же ПО.

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

это почти вин-стайл.
а вообще прозреваю костыли и велики при сборке.
глупость это.

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

в нём можно --prefix указывать? в документации по ubuild'ам про это не написано

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