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

это... пиши слакбилды :)

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

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

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

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

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

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

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

Не бывает.

Прямое.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Прямое.

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ты явно не понимаешь о чём говоришь.

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

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

несовместимость пакетов

Например?

так толсто что аж тонко

libav vs ffmpeg, например

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

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

коллизии, да.
и вообще это аналоги.

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

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

Кажется, я нашёл то что мне надо: tazpkg
http://doc.slitaz.org/en:handbook:packages

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

Тебе кажется ;)

почему?

paco