https://opennet.ru/openforum/vsluhforumID9/9434.html [ перетаскиваю из http://www.opennet.ru/openforum/vsluhforumID3/84013.html#148 и далее ]<br><br>&gt; Это совершенно не подразумевается. Особенно учитывая тот факт, что упрощённая<br>&gt; документация по сборке и помощь на форумах это не подразумевает, а в <br>&gt; Install большими красными буквами об этом не написано.<br><br>С ровными и оформленными по гнутым правилам (%name-%version/ в тарболе с названием %name-%version.tar.*) autoconf-based проектами основная проблема не в сборке (см. http://fly.osdn.org.ua/~mike/RPM/SPECS/_minimal.spec), а в метаданных -- хотя бы однострочное и более развёрнутое описание.<br><br>С группой ещё сложней -- можно попробовать автоматически категоризировать по README, ставить одно и то же значение (что плохо) или просто требовать задания вручную.<br><br>С лицензией вроде бы как можно сделать тесты на несколько распространённых случаев, но это вопрос ответственности и автоугадав тут IMCO неуместен.<br><br>Это по опыту создания спеков для таких -- вписываются название, версия (их можно брать из AC_INIT в configure https://opennet.ru/openforum/vsluhforumID9/9434.html#10 Fri, 20 Apr 2012 21:07:19 GMT &gt;[оверквотинг удален]<br>&gt; Помилуйте, да там тридцать или сколько уже лет утряхивают базовые-расширенные-перловые <br>&gt; и всякие corner cases. Это мощный хак, но никакой строгой <br>&gt; семантикой там и близко не пахнет, IMHO.<br>&gt;&gt;&gt; Вообще-то нет. Например, orbitz.com не только для программистов, но без глубоких <br>&gt;&gt;&gt; макросов вряд ли работал бы так же хорошо.<br>&gt;&gt; Так макросы по сути тот же самый императивный высокоуровневый код.<br>&gt; На орбитзах не так давно работали лисповые макросы четвёртого порядка, насколько знаю. <br>&gt; :) <br>&gt;&gt; Принципы хорошо познаются в динамике и визуализации. В моделях.<br>&gt; К слову о том же graphviz: http://fly.osdn.org.ua/~mike/img/m-p/targets_syslinux.png <br><br> https://opennet.ru/openforum/vsluhforumID9/9434.html#9 Tue, 17 Apr 2012 23:35:21 GMT &gt; Вот и не лезу...<br><br>А я лазил. Ибо нужно было. И обжигался.<br><br>&gt; И то спасибо за обсуждение.<br><br>Какое же это обсуждение? Так, упоминание при флейме.<br><br>&gt; Способность применить понятое для выхода за его рамки, например.<br><br>Это определение не по устройству, а по поведению. Зная устройство, можно узнать поведение. Зная поведение, нельзя узнать устройство.<br><br>&gt;&gt; Но тогда man китайская комната.<br>&gt; Не слышал, почитал; полагаю, у Сирла ошибка в четвёртой аксиоме. <br><br>Возможно, она не всегда верна. Скажем, http://www.langust.ru/review/lang_h02.shtml#02_01 , http://www.langust.ru/review/lang_h02.shtml#02_04<br><br>Ну и НЛП есть, а вот образного уже вроде нет.<br><br><br> https://opennet.ru/openforum/vsluhforumID9/9434.html#8 Tue, 17 Apr 2012 22:00:50 GMT &gt; Часто нужны универсальные. Скажем, замена swiftweasel. Или mplayer пересобрать.<br>&gt; Здесь широкие знания нужны.<br><br>Вот и не лезу...<br><br>&gt; Может, дождусь начала создания метарепозитария сырцов для создания пакетов<br>&gt; для разных дистрибутивив. Польза была бы большая.<br><br>И то спасибо за обсуждение.<br><br>&gt;&gt; Общие более дороги, хотя нередко и более осмысленны в долгосрочном плане.<br>&gt; Общие для создания частных.<br><br>Ой, я своё поделие mkimage-profiles уж второй год пилю...<br><br>&gt;&gt; Не-не-не, текст без картинки ещё бы воспринял, а вот анимация вместо текста <br>&gt;&gt; совсем не годится: это скорее впечатление, чем понимание. [...] <br>&gt; В зависимости от того, кто что понимает под пониманием.<br><br>Способность применить понятое для выхода за его рамки, например.<br><br>&gt; Но тогда man китайская комната.<br><br>Не слышал, почитал; полагаю, у Сирла ошибка в четвёртой аксиоме. Под фонарём искать грустно...<br> https://opennet.ru/openforum/vsluhforumID9/9434.html#7 Tue, 17 Apr 2012 21:07:32 GMT &gt; Так сами ж говорите, что это уже не совсем пользователь -- а <br>&gt; сборщик и администратор. <br><br>Это если вручную админить и собирать. Всё-таки, запуск checkinstall не требует квалификации и особого чтения документации.<br><br>&gt;А так -- юзер, просто юзер :)<br><br>И работаете, наверное, не в области IT.<br><br>&gt; Именно. И если обучиться собирать какие-то сильно нишевые пакеты быстрее, чем <br>&gt; ждать других -- то может иметь смысл освоить. <br><br>Часто нужны универсальные. Скажем, замена swiftweasel. Или mplayer пересобрать. Здесь широкие знания нужны.<br><br>&gt; Думаю, нереально. Можно добиваться двух вещей: <br>&gt; - большей полезности уже вложенной работы; <br>&gt; - меньшей работы для той же полезности.<br><br>Может, дождусь начала создания метарепозитария сырцов для создания пакетов для разных дистрибутивив. Польза была бы большая.<br><br>&gt; В том числе, но необязательно: библиотеки могут быть полезными за счёт dlopen(), <br>&gt; картинки тем могут быть нужными для штатного отображения UI, с какими-то <br>&gt; конкретными версиями libdb4 могут быть извес https://opennet.ru/openforum/vsluhforumID9/9434.html#6 Tue, 17 Apr 2012 19:12:11 GMT &gt; Это здорово, но для linux были бы гораздо более полезны другие системы. <br>&gt; По автоматизированным сборке и администрированию на уровне пользователя, например.<br><br>Так сами ж говорите, что это уже не совсем пользователь -- а сборщик и администратор. Мне удаётся отделываться тем, что буржуи порой обзывают wearing $that hat -- когда всё-таки надо что-то собрать или уадминить, приходится напяливать соответствующую шляпу и орудовать. А так -- юзер, просто юзер :) Вот, vimperator/pentadactyl "не осилил", посмотрев и пощупав (и сидя в vim).<br><br>&gt; Ещё раз - смотря чему обучен.<br><br>Именно. И если обучиться собирать какие-то сильно нишевые пакеты быстрее, чем ждать других -- то может иметь смысл освоить. Сильно благодарен Владимиру Бормотову (тогда из Black Cat Linux team), помогшему верно оценить страшность конкретно этих горшков.<br><br>&gt; По документации видно, что нужен пакет с зависимостями. А мы как раз <br>&gt; говорим от тарболлах, в которых эти зависимости создать нужно. ;)<br><br>А, ну в этом плане да. Я пару сообщений и https://opennet.ru/openforum/vsluhforumID9/9434.html#5 Tue, 17 Apr 2012 12:00:16 GMT &gt; Думаю, куда раньше -- см. историю MUMPS/ISO M. <br><br>Ну я с точки зрения пользователя говорю. То есть с учётом доступности этих программ на тех же носителях.<br><br>&gt; Кстати, GT.M под <br>&gt; линукс вполне доступна и развивается.<br><br>Это здорово, но для linux были бы гораздо более полезны другие системы. По автоматизированным сборке и администрированию на уровне пользователя, например.<br><br>&gt; Как раз не при сборке, а при установке. Только они жёстче <br>&gt; USE. И опять же это не достоинство per se, а <br>&gt; один из концов качели "гибкость-надёжность".<br><br>Не знаю кому как, а я Debian выбрал в том числе из-за них. Мусора в системе поубавилось, стабильность как раз Debian радует. Но да, самому такие пакеты собирать - уровень более высокий.<br><br>&gt; Ну так всё постепенно.<br><br>Ну, вот мне хотелось бы видеть впереди готовую автоматизацию, даже с постепенным движением.<br><br><br>&gt; В альте и тогда работал buildreq, false positive'ил всякие кривые тесты на <br>&gt; фортран в configure: http://lists.altlinux.org/pipermail/devel/2004-December/109425.ht https://opennet.ru/openforum/vsluhforumID9/9434.html#4 Tue, 17 Apr 2012 10:54:22 GMT &gt; Такие системы в 2000 были под DOS для медицины, к примеру.<br><br>Думаю, куда раньше -- см. историю MUMPS/ISO M. Кстати, GT.M под линукс вполне доступна и развивается.<br><br>&gt;&gt; Не уверен, что их вообще стоит получать. Польза местами понятна, вред <br>&gt;&gt; -- тоже, неясен итоговый баланс.<br>&gt; Мягкие зависимости - они ещё позволяют ту самую гибкость при компилировании получить. <br>&gt; Типа Use-флагов.<br><br>Как раз не при сборке, а при установке. Только они жёстче USE. И опять же это не достоинство per se, а один из концов качели "гибкость-надёжность".<br><br>&gt; Осваивание поддержки - это осваивание существующего инструментария.<br>&gt; Полезно, конечно, но эффект не тот, как при автоматизации.<br><br>Ну так всё постепенно.<br><br>&gt; Я давно программы не собирал, может, всё сильно поменялось, но во времена<br>&gt; 2004-2006 годов создание пакетов в плане вещей типа зависимостей, были ещё рутиной.<br><br>В альте и тогда работал buildreq, false positive'ил всякие кривые тесты на фортран в configure: http://lists.altlinux.org/pipermail/devel/2004-December/ https://opennet.ru/openforum/vsluhforumID9/9434.html#3 Sat, 14 Apr 2012 21:49:42 GMT &gt; Это как раз уже к полной автоматизации и ближе, есть много осмысленных <br>&gt; промежуточных этапов.<br><br>Да нет, это просто такой вид контекстно-зависимой документации, когда документация является частью программы. Я же не про замену человека ЭС. Просто семантическая разметка текста. Рутина. Система поддержки принятия решений. Ну и какой-нибудь расширяемый анализатор. Такие системы в 2000 были под DOS для медицины, к примеру. Просто устроены. А эффект заметный.<br><br>Сейчас та же документация имеет простой текстовой вид. Даже просто понять её тяжело. Как говорится, лучше один раз увидеть... А увидеть как раз нельзя, ибо просто текст.<br><br>&gt; Не уверен, что их вообще стоит получать. Польза местами понятна, вред <br>&gt; -- тоже, неясен итоговый баланс.<br><br>Мягкие зависимости - они ещё позволяют ту самую гибкость при компилировании получить. Типа Use-флагов.<br><br>&gt; Если в его задачу входит пользоваться софтиной, просто к ней прилагается понимание <br>&gt; большего удобства эксплуатации в виде пакета -- то на большого пользователя <br> https://opennet.ru/openforum/vsluhforumID9/9434.html#2 Sat, 14 Apr 2012 16:46:30 GMT &gt; Вопрос не в полной автоматизации, а в обучаемой экспертной системе для сборки пакетов.<br><br>Это как раз уже к полной автоматизации и ближе, есть много осмысленных промежуточных этапов.<br><br>&gt; Которую при использовании можно было бы совершенствовать и в плане знаний,<br>&gt; и в плане блока анализа исходников на тему автоматизированного поиска зависимостей.<br><br>Скажем так: людей, с которыми можно подобным озадачиваться -- я знаю. Поэтому если будет возможность и уместность, то просто быстрей к тому придёт, чем потихоньку.<br><br>&gt; Скажем, мягкие зависимости автоматически не получить, это уже база знаний нужна.<br><br>Не уверен, что их вообще стоит получать. Польза местами понятна, вред -- тоже, неясен итоговый баланс.<br><br>&gt; И опять таки, вы говорите про сопровождающего. Которому придется читать про технику <br>&gt; сборки. Я про пользователя. Которому посоветовали в книжках/на форумах собрать <br>&gt; пакет. Ему совершенно неочевидно всё то, о чём говорите вы. И задачи у него другие<br>&gt; - поменять зависимости, наложить патч, а не правильн