> Вопрос не в полной автоматизации, а в обучаемой экспертной системе для сборки пакетов.Это как раз уже к полной автоматизации и ближе, есть много осмысленных промежуточных этапов.
> Которую при использовании можно было бы совершенствовать и в плане знаний,
> и в плане блока анализа исходников на тему автоматизированного поиска зависимостей.
Скажем так: людей, с которыми можно подобным озадачиваться -- я знаю. Поэтому если будет возможность и уместность, то просто быстрей к тому придёт, чем потихоньку.
> Скажем, мягкие зависимости автоматически не получить, это уже база знаний нужна.
Не уверен, что их вообще стоит получать. Польза местами понятна, вред -- тоже, неясен итоговый баланс.
> И опять таки, вы говорите про сопровождающего. Которому придется читать про технику
> сборки. Я про пользователя. Которому посоветовали в книжках/на форумах собрать
> пакет. Ему совершенно неочевидно всё то, о чём говорите вы. И задачи у него другие
> - поменять зависимости, наложить патч, а не правильно, в соответствии с требованиями,
> пакет собрать.
Если в его задачу входит пользоваться софтиной, просто к ней прилагается понимание большего удобства эксплуатации в виде пакета -- то на большого пользователя может образоваться маленький майнтейнер. Я такое и проходил, и наблюдал -- когда человека задалбывает делать одни и те же алгоритмизируемые действия руками либо дёргать "уже майнтейнера" и он, отталкиваясь от тарбола или чаще уже собранного пакета, начинает осваивать поддержку пакетов.
По-моему, не стоит заранее считать пользователя необучаемым. :)
> И тут сюрприз - пакет, собранный не в чистой системе, может неправильно заработать.
Ну так в том же альте очень большие усилия были положены на осмысление и реализацию воспроизводимых сборок; это многим пользователям помогло заняться улучшением применяемых пакетов.
Соответственно и на обучение людей усилия были положены в сумме за прошедшие годы огромные. Это не менее важно, чем инструментальная среда.
> То есть несовершенство системы сборки, которую приходится запускать по непонятной
> для пользователя причине в изменённом внешнем окружении, которое создавать нужно
> под каждый пакет, ему неочевидна.
Это вопрос полноты указанных сборочных зависимостей -- я не просто так сослался на альтовский buildreq, который предоставляет их надмножество.
> Минуточку. Я как раз говорил о том, что для автосборки нужна ручная работа.
А я и обращал Ваше внимание -- что не для всякой. Например, угрозы собрать CPAN в сизиф уже звучали. :)
> Хорошо устроенный репозиторий - ручная работа, а не автоматизированная с анализом
> исходников. И, что жаль, таких универсальных репозиториев, мета, если хотите, но
> не CPAN/CRAN/CTAN, нет.
Для общего случая -- нет; и кстати, простейшее возвращение *.lsm в тарболы уже бы сделало шаг в таком направлении (по части метаинформации).
> То есть у вас, в альте, автоматизация работает хорошо?
Довольно-таки; и над ней постоянно работают в плане улучшения.
>> Не знаю, но как минимум автоконфовых весьма много. Не во всех
>> есть configure.ac, кстати.
> То есть ограниченные случаи - это _все_ autoconf-based?
Нет. Не все autoconf-based получится собрать без применения головы, и некоторые другие типичные случаи тоже подходят для автоматизации сборки.
> Вопрос не в обязаны/не обязаны, а в том, что из комментариев код не следует.
Поэтому и удивился, когда Вы их назвали спецификацией -- вот и попытался сообразить, какие из виденных более-менее в ту сторону...
>> Это мощный хак, но никакой строгой семантикой там и близко не пахнет, IMHO.
> Под языком я C имел ввиду. И причём тут утряхивание кода?
А -- я было понял, что про регэкспы.
>> На орбитзах не так давно работали лисповые макросы четвёртого порядка, насколько знаю.
> А библиотеки - не суть код высшего порядка?
Это тоже обобщение, но степень его интегрируемости и реюзабельности в рамках конкретнго проекта обычно отличается. А вообще макросы применяются и в библиотеках. :)
>> К слову о том же graphviz: http://fly.osdn.org.ua/~mike/img/m-p/targets_syslinux.png
> Попробуйте по подобному графу, скажем, анатомию изучить
Пробовал, в нулевом приближении годится; а без нулевого приближения может быть опасно делать первое (т.е. углубиться в конкретный орган, но не понять его взаимосвязь со всем организмом или хотя бы с непосредственно связанными физически/биохимически/сигнально).
> И да, это всего лишь картинка, а не интерактивный динамический графический
> интерфейс к некой предметной области.
(читая между строк) Интерфейс к области делается легче, чем область к интерфейсу.
Вариант для распечатки
(ok) on 14-Апр-12, 16:19 
