gentoo

^^^^

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

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

Дак вот она же, в билде в массиве source и указывается. Любая.

Для каждого? А если билдов с полтыщи?

Такое впечатление, что ты пишешь формат ебилда и Portage/Paludis

Дурацкая затея. Программа загрузки должна браться из переменной окружения или проверять наличие wget/curl.

Подискутировать? Это сейчас так назвается, да?

Реквестирую IRC каналы

тоже ищу нормальные

Зайди на Freenode.

Лучше указывать просто протокол (http, ftp, git...) и сам URL, а где-нибудь в недрах конфига есть табличка протокол->команда.

Действительно, кто-нибудь напишет wget, а его в системе-то и нету. А есть curl. Гипотетические юзеры тебя проклянут. И ещё, задумайся, стоит ли использовать массивы с магической семантикой, когда вместо них можно использовать map'ы с возможностью добавления новых ключей и проверки старых. В общем, я за именованные параметры.

А зеркала репозиториев как делать?

Ну и да - тюринг-полные конфиги - это в общем случае плохо. И ошибку проще допустить, и всё-таки небезопасно.

Концепт эксплоита: вместо wget мейнтейнер-злоумышленник использует скрипт на perl, который на первый взгляд ходит curl'ом по зубодробительному URL, а на самом деле этот URL расшифровывает и выполняет а-ля та самая строчка на перле..

Spoofing

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

unixforum.org (админ и его модеры - му, но остальные отличные люди)
linuxforum.ru (среди модеров есть му, но и не мало нормальных и интересных людей)
/me, однако, на обоих забанен.

Реквестирую IRC каналы и Jabber конференции, где можно свободно говорить на тему линукса

#linux, linux@conference.<jabber.domain>

и один файл в массиве состоит из двух элементов, - (1) само название конечного файла, к которому сборщик будет обращаться, и (2) команда которая тупо через какой-нибудь eval будет выполняться, для получения этого файла.

Я думаю, подход, где только ссылка лучше — можно юзать любую качалку, а не только wget. С другой стороны, можно конечно предусмотреть какой-нибудь git clone... Тогда можно ввести ещё один параметр с командой, которая будет исполнятся, если переменная типа $GIT_DOWNLOAD не задана

>С другой стороны, можно конечно предусмотреть какой-нибудь git clone...

В арче когда-то тупо пропускали source (кроме патчей/иконок/whatever) в этом случае и делали git clone в build(). Не знаю, как сейчас, впрочем.

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

source=(
        "$name-$version.tar.gz" "wget -c ftp://ftp.mutt.org/mutt/devel/$name-$version.tar.gz"
)

prepare() {
wget -c ftp://ftp.mutt.org/mutt/devel/$name-$version.tar.gz
tar xf $name-$version.tar.gz
}

Про глупость с командами тебе уже сказали. Что еще не нравится в makepgk/pacman?

makepkg хороший, учитывает все ньюансы для сборки пакетов (как то, например, последующее удаление не нужной документации/файлов, strip бинарников, сжатие man'ов). pacman не нравится тем, что это программа; и в целом арч не устраивает форматом пакетов (их излишеством).

от пакетного менеджера мне нужно: 1) контроль установленных в системе файлов 2) больше ничего в нем быть не должно. поэтому взялся писать пакетный менеджер в 100-200 строчек кода, в трех скриптах pkg_{make,add,delete}.sh, лишь для удобства добавления/удаления файлов в системе. три скрипта (трудно назвать «пакетным менеджером»), которые должны уметь: собирать пакет (.build файл похожий на PKGBUILD), при его установке (распаковке) записывать список файлов в «/var/lib/pkg/<name>-<version>/files» чтобы знать какие файлы принадлежат какой программе, и при его удалении просто пройтись по списку файлов чтобы удалить их. по сути я изобретаю уже существующий «make install» и «make uninstall». у знающего человека это заняло бы один вечер, а я второй день читаю http://wiki.bash-hackers.org/doku.php :)

Раз хочется простоты, можешь глянуть на pkgsrc.