Может кому и лучше автотулзы попилить, но в данном случае задействован старый армейский принцип -"нужно, чтобы работало, вперёд — рожай!" «Взял сорцы там–то, приложил патч такой, задал команду такую–то. Пользуйся.» Всё чётко и ясно.
А на m4 учиться разговаривать честно говоря лень. И за всё «человечество» впрягаться тоже лень. Мы уж по–стариковски в кернел дебаггере на дампы, под чаёк подивимся вместо этого. ;–)

Ждём патчик с «инструкциями» если не жалко отдавать. :–) Можно на мыло: zharik-хрю-gmx–li. Ну фтп и в нашем работает, а что с саб-шеллом–то? А по зип–файлам он ходит? ;–)

это понятно. просто лень, да и некогда особо самому собирать ;)

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

>1) Вероятная несовместимость с библиотеками уже установленными в системе и с косяками в самом системе.

несовместимость чего с чем? Софта, поставленного из бинарников между собой? Нормальный пакетный менеджер должен это всё разруливать

>2) Желающих работать в «службе поддержки» и выяснять вариации пункта 1) на постоянной основе как правило нет. Времени и желания на такое бесполезное (для разработчика) занятие не предвидится.

возьмём к примеру, Gentoo. «конфигурация системы сборки» = cat /etc/{make.conf,/portage/package.{use,mask,keywords,unmak}} или emerge -–info. Можно поставить «слотовый» ебилд — рядом gcc 4.4.2 и 4.3.4, например, binutils с gold linker и с обычным ld, php4 и php5 и переключаться между ними через gcc–config, binutils–config, и т.п.

Хотя более правильный подход — это система вроде Nix OS, nixpkgs. Пакетный менеджер на функциональном языке программирования, без побочных эффектов — то есть, все конфликты автоматически не допускаются, на уровне дизайна пакетного менеджера. А конфиги, изменяемое состояние, настройки «пакетов» являются логическими-формулами–предикатами в пакетном менеджере, то есть перегенерируются из функциональных программ. То есть, всегда можно откатиться на предыдущее состояние.

Вариант «для бедных», с «палками и верёвками» — поставил хайку из флешки, сделал в корне git init/git add ./ git commit -m “initial nightly SVN r…” /git tag initial — и имеем «версионированную ФС». Я так сделал на чистом разделе — 600М система, 200М папка .git в корне раздела.

Очень пригодилась, когда наткнулся на глюк с шрифтами — копируем папку с .ttf фонтами из винды, потом выбираем красивые и на некоторых шрифтах терминал сворачивается в кучку — неправильно читаются метрики шрифтов. В меню приложений не прорисовывается ни одна надпись, в файрфоксе тоже не видно ни одного шрифта. Соответственно, не можем сменить назад на дефотлные в окошке preferences/fonts — кнопки, меню и комбобоксы не прорисовываются.

фигня вопрос — удаляем /home/…/font settings, и шрифты через git reset HEAD -r initial — и имеем нормальную, «чистую» систему.

>3) Опубликовал — отвечай. Способность собрать программу самому по чёткой инструкции есть своего рода «вступительный ценз» — если кто–то не способен даже на это — время потраченное на консультирование его определенно уйдёт впустую. Пусть ждет систему пакажей.

Просьба указывать в таких инструкциях всю информацию, нужную нормальному пакетному менеджеру — версию nightly сборки/gcc/autotools/пакетов/ключей ./configure и CFLAGS, c которыми точно собираются пакеты. Чтобы облегчить пункт 1).
То есть да, инструкция нужна *чёткая*, *конкретная* — что качать, как ставить, каких версий, или не нужна никакая вообще.

>4) Система динамично изменяется — несовместимость из пункта 1) может возникнуть уже завтра. Да, мы не даем вам «рыбу», но мы даем вам удочку, чтобы ловить эту «рыбу» тогда когда она вам потребуется.

Ах, как это напоминает грабли в Gentoo при обновлении профиля/тулчейна/мажорных версий софта и замаскированных пакетов. Тоже случаются грабли, тоже время от времени «портедж» ломается в основной ветке. Но, благодаря пониманию и гуглению и общей понятности пакетного менеджера/системы сборки понятно, где сломалось и как починить. Поэтому, когда ломается — не смертельно.

То есть, мне кажется в Хайку имеет смысл портировать нормальный source–based пакетный менеджер вроде emerge/paludis/nixpkgs/pkgbuild из арча и собирать уже им, а не изобретать велосипед.