The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"автопакетирование тарболов"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Программирование под UNIX (Разное)
Изначальное сообщение [ Отслеживать ]

"автопакетирование тарболов"  +/
Сообщение от Michael Shigorin email(ok) on 14-Апр-12, 16:19 
[ перетаскиваю из https://www.opennet.ru/openforum/vsluhforumID3/84013.html#148 и далее ]

> Это совершенно не подразумевается. Особенно учитывая тот факт, что упрощённая
> документация по сборке и помощь на форумах это не подразумевает, а в
> Install большими красными буквами об этом не написано.

С ровными и оформленными по гнутым правилам (%name-%version/ в тарболе с названием %name-%version.tar.*) autoconf-based проектами основная проблема не в сборке (см. http://fly.osdn.org.ua/~mike/RPM/SPECS/_minimal.spec), а в метаданных -- хотя бы однострочное и более развёрнутое описание.

С группой ещё сложней -- можно попробовать автоматически категоризировать по README, ставить одно и то же значение (что плохо) или просто требовать задания вручную.

С лицензией вроде бы как можно сделать тесты на несколько распространённых случаев, но это вопрос ответственности и автоугадав тут IMCO неуместен.

Это по опыту создания спеков для таких -- вписываются название, версия (их можно брать из AC_INIT в configure.ac), лицензия, краткое/развёрнутое описание, заполняется запись в %changelog, прогоняется buildreq с установкой в хост-систему или сборочный чрут зависимостей до удовлетворительного прохождения стадий конфигурирования и сборки; пакет собирается по полученному спеку начисто, проверяется и в первом приближении всё.

Ручную стадию с добиванием зависимостей в принципе можно автоматизировать по анализу configure.ac и требуемых pkgconfig-файлов; по крайней мере обсуждение встречал, реализации пока не видел.

Наверное, автоматизировать 80% работы по упакечиванию ~50% случаев вполне реально, добиваться 100% замещения работы для тех же случаев уже сильно сложнее, а для 100% случаев -- нереально (думаю, даже если изначально ограничиться autoconf и cmake).

> А также, что при сборке нет warning'ов. Ну и по многим другим причинам.

warning'и для рассматриваемого случая можно вылавливать и добавлением в CFLAGS -Werror.

>> А, простите.  Имел в виду то, что в рамках текущей штатной
>> архитектуры и реализации CPAN собирается необходимое и достаточное
>> количество метаинформации для упакечивания модулей.
> Нет, что вы имели ввиду, когда просили объяснить, какую ручную работу можно
> выкинуть?

Просил (https://www.opennet.ru/openforum/vsluhforumID3/84013.html#211) объяснить на примере Makefile-GraphViz в CPAN -- какая ручная работа, проведённая для создания и публикации данного тарбола в этом репозитории с целью возможности его развёртывания при помощи perl -MCPAN, является излишней для задачи автоупакечивания.

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

На самом деле пришлось запускать cpan2rpm --version 0.20 Makefile-GraphViz, предварительно поставив perl-Module-Build, perl-GraphViz, perl-Makefile-Parser по вполне ловящимся паттернам ненаходимости (эти модули есть в сизифе).

Результат вот -- погоняю с mkimage-profiles да и отправлю в Sisyphus:
http://fly.osdn.org.ua/~mike/RPM/SPECS/perl-Makefile-GraphVi...
http://fly.osdn.org.ua/~mike/RPM/SRPMS/perl-Makefile-GraphVi...
http://fly.osdn.org.ua/~mike/RPM/RPMS/noarch/perl-Makefile-G...

>> Скорее нет, по крайней мере не замечал.
> Автоматические инструменты не имеют спроса?

Отчасти "китайцы дешевле", отчасти -- автоматизируются частные случаи под рукой и этого вроде как достаточно (довести "свой" инструмент до пригодного другим всё-таки намного сложней бывает).

>> Не-а, скорее autoconf-based.
> А разве не большинство тарболлов не autoconf-based?

Не знаю, но как минимум автоконфовых весьма много.  Не во всех есть configure.ac, кстати.

> Ну вот смотрите, у вас есть программа, код. Он состоит из собственно
> кода и комментов. Без комментов вы код не поймёте.

Зависит, но пусть.

> Без кода комменты работать не будут. ;) Получается так: у вас есть спецификация
> функций в виде комментов, которые вы пишете сами, и её же описание на языке
> программирования. А вот писать такие комменты, чтобы по ним код генерировался, нельзя.

В какой-то мере да, комментарии могут отражать намерение и тем быть спецификацией.  Но они не обязаны являться _полным_ описанием намерения и обычно являются скорее _дополнением_.  Ужасно бестолково прокомментированный код (нередко под заданный процент комментариев) встречался и не радовал.

> Или, например, возьмём регекспы. Такой мощный механизм поиска. Однако часто избыточный.

[...]
> Казалось бы, язык со строкой семантикой. А дедукция невозможна.

Помилуйте, да там тридцать или сколько уже лет утряхивают базовые-расширенные-перловые и всякие corner cases.  Это мощный хак, но никакой строгой семантикой там и близко не пахнет, IMHO.

>> Вообще-то нет.  Например, orbitz.com не только для программистов, но без глубоких
>> макросов вряд ли работал бы так же хорошо.
> Так макросы по сути тот же самый императивный высокоуровневый код.

На орбитзах не так давно работали лисповые макросы четвёртого порядка, насколько знаю. :)

> Принципы хорошо познаются в динамике и визуализации. В моделях.

К слову о том же graphviz: http://fly.osdn.org.ua/~mike/img/m-p/targets_syslinux.png

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "автопакетирование тарболов"  +/
Сообщение от tmp (ok) on 14-Апр-12, 18:08 
>[оверквотинг удален]
> чрут зависимостей до удовлетворительного прохождения стадий конфигурирования и сборки;
> пакет собирается по полученному спеку начисто, проверяется и в первом приближении
> всё.
> Ручную стадию с добиванием зависимостей в принципе можно автоматизировать по анализу configure.ac
> и требуемых pkgconfig-файлов; по крайней мере обсуждение встречал, реализации пока не
> видел.
> Наверное, автоматизировать 80% работы по упакечиванию ~50% случаев вполне реально, добиваться
> 100% замещения работы для тех же случаев уже сильно сложнее, а
> для 100% случаев -- нереально (думаю, даже если изначально ограничиться autoconf
> и cmake).

Вопрос не в полной автоматизации, а в обучаемой экспертной системе для сборки пакетов. Которую при использовании можно было бы совершенствовать и в плане знаний, и в плане блока анализа исходников на тему автоматизированного поиска зависимостей. Скажем, мягкие зависимости автоматически не получить, это уже база знаний нужна.

И опять таки, вы говорите про сопровождающего. Которому придется читать про технику  сборки. Я про пользователя. Которому посоветовали в книжках/на форумах собрать пакет. Ему совершенно неочевидно всё то, о чём говорите вы. И задачи у него другие - поменять зависимости, наложить патч, а не правильно, в соответствии с требованиями,  пакет собрать. И тут сюрприз - пакет, собранный не в чистой системе, может неправильно заработать. Хотя ошибок того же ./configure, к которым он привыкнет при неполадках при сборке, в этомплане нет. То есть несовершенство системы сборки, которую приходится запускать по непонятной для пользователя причине в изменённом внешнем окружении, которое создавать нужно под каждый пакет, ему неочевидна.

> warning'и для рассматриваемого случая можно вылавливать и добавлением в CFLAGS -Werror.

Я про сборку говорю. А не компиляцию.  А ворнинги компиляции - вообще чёрная магия для пользователя. Сырцы он уже править руками не будет.

> Просил (https://www.opennet.ru/openforum/vsluhforumID3/84013.html#211) объяснить
> на примере Makefile-GraphViz в CPAN -- какая ручная работа, проведённая для
> создания и публикации данного тарбола в этом репозитории с целью возможности
> его развёртывания при помощи perl -MCPAN, является излишней для задачи автоупакечивания.

Минуточку. Я как раз говорил о том, что для автосборки нужна ручная работа. Хорошоустроенный репозиторий - ручная работа, а не автоматизированная с анализом исходников. И, что жаль, таких универсальных репозиториев, мета, если хотите, но не CPAN/CRAN/CTAN, нет.  

> Отчасти "китайцы дешевле", отчасти -- автоматизируются частные случаи под рукой и этого
> вроде как достаточно (довести "свой" инструмент до пригодного другим всё-таки намного
> сложней бывает).

То есть у вас, в альте, автоматизация работает хорошо?


> Не знаю, но как минимум автоконфовых весьма много.  Не во всех
> есть configure.ac, кстати.

То есть ограниченные случаи - это _все_ autoconf-based?

> В какой-то мере да, комментарии могут отражать намерение и тем быть спецификацией.
>  Но они не обязаны являться _полным_ описанием намерения и обычно
> являются скорее _дополнением_.  Ужасно бестолково прокомментированный код (нередко под
> заданный процент комментариев) встречался и не радовал.

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

> Помилуйте, да там тридцать или сколько уже лет утряхивают базовые-расширенные-перловые
> и всякие corner cases.  Это мощный хак, но никакой строгой
> семантикой там и близко не пахнет, IMHO.

Под языком я C имел ввиду. И причём тут утряхивание кода? Код регекспов есть. Семантика C есть. По идее, возможна дедукция.


> На орбитзах не так давно работали лисповые макросы четвёртого порядка, насколько знаю.
> :)

А библиотеки - не суть код высшего порядка?


> К слову о том же graphviz: http://fly.osdn.org.ua/~mike/img/m-p/targets_syslinux.png

Попробуйте по подобному графу, скажем, анатомию изучить, без разреза организма и наглядного представления нутра. Да или то же железо ПК, скажем, устройство матери. И да, это всего лишь картинка, а не интерактивный динамический графический интерфейс к некой предметной области. Лучше, чем ничего. Но по типу it sucks less.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "автопакетирование тарболов"  +/
Сообщение от Michael Shigorin email(ok) on 14-Апр-12, 20:46 
> Вопрос не в полной автоматизации, а в обучаемой экспертной системе для сборки пакетов.

Это как раз уже к полной автоматизации и ближе, есть много осмысленных промежуточных этапов.

> Которую при использовании можно было бы совершенствовать и в плане знаний,
> и в плане блока анализа исходников на тему автоматизированного поиска зависимостей.

Скажем так: людей, с которыми можно подобным озадачиваться -- я знаю.  Поэтому если будет возможность и уместность, то просто быстрей к тому придёт, чем потихоньку.

> Скажем, мягкие зависимости автоматически не получить, это уже база знаний нужна.

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

> И опять таки, вы говорите про сопровождающего. Которому придется читать про технику
> сборки. Я про пользователя. Которому посоветовали в книжках/на форумах собрать
> пакет. Ему совершенно неочевидно всё то, о чём говорите вы. И задачи у него другие
> - поменять зависимости, наложить патч, а не правильно, в соответствии с требованиями,
>  пакет собрать.

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

По-моему, не стоит заранее считать пользователя необучаемым. :)

> И тут сюрприз - пакет, собранный не в чистой системе, может неправильно заработать.

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

Соответственно и на обучение людей усилия были положены в сумме за прошедшие годы огромные.  Это не менее важно, чем инструментальная среда.

> То есть несовершенство системы сборки, которую приходится запускать по непонятной
> для пользователя причине в изменённом внешнем окружении, которое создавать нужно
> под каждый пакет, ему неочевидна.

Это вопрос полноты указанных сборочных зависимостей -- я не просто так сослался на альтовский 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
> Попробуйте по подобному графу, скажем, анатомию изучить

Пробовал, в нулевом приближении годится; а без нулевого приближения может быть опасно делать первое (т.е. углубиться в конкретный орган, но не понять его взаимосвязь со всем организмом или хотя бы с непосредственно связанными физически/биохимически/сигнально).

> И да, это всего лишь картинка, а не интерактивный динамический графический
> интерфейс к некой предметной области.

(читая между строк) Интерфейс к области делается легче, чем область к интерфейсу.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "автопакетирование тарболов"  +/
Сообщение от tmp (ok) on 15-Апр-12, 01:49 
> Это как раз уже к полной автоматизации и ближе, есть много осмысленных
> промежуточных этапов.

Да нет, это просто такой вид контекстно-зависимой документации, когда документация является частью программы. Я же не про замену человека ЭС. Просто семантическая разметка текста. Рутина. Система поддержки принятия решений. Ну и какой-нибудь расширяемый анализатор. Такие системы в 2000 были  под DOS для медицины, к примеру. Просто устроены. А эффект заметный.

Сейчас та же документация имеет простой текстовой вид. Даже просто понять её тяжело. Как говорится, лучше один раз увидеть... А увидеть как раз нельзя, ибо просто текст.

> Не уверен, что их вообще стоит получать.  Польза местами понятна, вред
> -- тоже, неясен итоговый баланс.

Мягкие зависимости - они ещё позволяют ту самую гибкость при компилировании получить. Типа Use-флагов.

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

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

> По-моему, не стоит заранее считать пользователя необучаемым. :)

Обученный некоторым вещам пользователь перестаёт быть пользователем. ;)

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

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

> А я и обращал Ваше внимание -- что не для всякой.  
> Например, угрозы собрать CPAN в сизиф уже звучали. :)

Чтобы собирать CPAN, нужно сначала было его создать. Вручную. ;)

> Довольно-таки; и над ней постоянно работают в плане улучшения.

А какие названия программ?

> Нет.  Не все autoconf-based получится собрать без применения головы, и некоторые
> другие типичные случаи тоже подходят для автоматизации сборки.

Тогда ещё раз: что понимается под ограниченным числом случаев? Какой признак того, что пакет автоматически зависимости получит? Скажем, какие-то типичные пакеты или количество зависимостей?

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

А комментарии не спецификация? Типы входных данных, типы выходных, исключения. Мало?

>>> К слову о том же graphviz: http://fly.osdn.org.ua/~mike/img/m-p/targets_syslinux.png
>> Попробуйте по подобному графу, скажем, анатомию изучить
> Пробовал, в нулевом приближении годится;

Вы анатомию изучали по графу названий органов и систем, а не по монтажной схеме?

>> И да, это всего лишь картинка, а не интерактивный динамический графический
>> интерфейс к некой предметной области.
> (читая между строк) Интерфейс к области делается легче, чем область к интерфейсу.

Графический интерфейс вообще сложно делать. Если, конечно,  под таким интерфейсом формочки не понимать.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "автопакетирование тарболов"  +/
Сообщение от Michael Shigorin email(ok) on 17-Апр-12, 14:54 
> Такие системы в 2000 были  под DOS для медицины, к примеру.

Думаю, куда раньше -- см. историю MUMPS/ISO M.  Кстати, GT.M под линукс вполне доступна и развивается.

>> Не уверен, что их вообще стоит получать.  Польза местами понятна, вред
>> -- тоже, неясен итоговый баланс.
> Мягкие зависимости - они ещё позволяют ту самую гибкость при компилировании получить.
> Типа Use-флагов.

Как раз не при сборке, а при установке.  Только они жёстче USE.  И опять же это не достоинство per se, а один из концов качели "гибкость-надёжность".

> Осваивание поддержки - это осваивание существующего инструментария.
> Полезно, конечно, но эффект не тот, как при автоматизации.

Ну так всё постепенно.

> Я давно программы не собирал, может, всё сильно поменялось, но во времена
> 2004-2006 годов создание пакетов в плане вещей типа зависимостей, были ещё рутиной.

В альте и тогда работал buildreq, false positive'ил всякие кривые тесты на фортран в configure: http://lists.altlinux.org/pipermail/devel/2004-December/1094... :)

>> По-моему, не стоит заранее считать пользователя необучаемым. :)
> Обученный некоторым вещам пользователь перестаёт быть пользователем. ;)

Не могу согласиться -- себя считаю преимущественно пользователем. (:

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

> И да, это не отменяет сложности создания чистого окружения для каждого пакета.
> Даже не в плане знаний, а в плане необходимости держать несколько таких окружений.

Брр, в альте автоматически делается hasher-ом (с кэшированием базовой сборочной системы, разумеется).  Быстро, сравнительно дёшево, воспроизводито.

>> А я и обращал Ваше внимание -- что не для всякой.
>> Например, угрозы собрать CPAN в сизиф уже звучали. :)
> Чтобы собирать CPAN, нужно сначала было его создать. Вручную. ;)

С этим спору нет, но о том и говорил -- что создавался он для _другой_ цели (которую выполняет), а в качестве _побочного_ эффекта -- возможно, совсем не предполагавшегося закладывавшими правила -- получился ещё и такой :)

>> Довольно-таки; и над ней постоянно работают в плане улучшения.
> А какие названия программ?

buildreq, sisyphus_check, hasher, qa-robot, gear/girar/girar-builder, jppimport, fcimport (приблизительно по возрасту)

Обсуждения можно поискать по слову incominger.

>> Нет.  Не все autoconf-based получится собрать без применения головы, и некоторые
>> другие типичные случаи тоже подходят для автоматизации сборки.
> Тогда ещё раз: что понимается под ограниченным числом случаев? Какой признак того,
> что пакет автоматически зависимости получит?

Наличие в нём достаточного для этого количества метаинформации в пригодном к автоматическому извлечению виде.  Это необходимое, но не достаточное условие.

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

Конечно, мало.  Это описание фронта и тыла слона, но не его состава и жизнедеятельности.

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

По большей части вообще по тексту, а что?  По фотографии было бы хуже, чем по схематическому рисунку; а и ему, возможно, предпочёл бы граф для утряски понимания взаимодействий.  Из смежного -- попробуйте представить себе цикл Кребса "по монтажной схеме". :)

>> (читая между строк) Интерфейс к области делается легче, чем область к интерфейсу.
> Графический интерфейс вообще сложно делать. Если, конечно, под таким интерфейсом
> формочки не понимать.

Да, конечно.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "автопакетирование тарболов"  +/
Сообщение от tmp (ok) on 17-Апр-12, 16:00 
> Думаю, куда раньше -- см. историю MUMPS/ISO M.

Ну я с точки зрения пользователя говорю. То есть с учётом доступности этих программ на тех же носителях.

> Кстати, GT.M под
> линукс вполне доступна и развивается.

Это здорово, но для linux были бы гораздо более полезны другие системы. По автоматизированным сборке и администрированию на уровне пользователя, например.

> Как раз не при сборке, а при установке.  Только они жёстче
> USE.  И опять же это не достоинство per se, а
> один из концов качели "гибкость-надёжность".

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

> Ну так всё постепенно.

Ну, вот мне хотелось бы видеть впереди готовую автоматизацию, даже  с постепенным движением.


> В альте и тогда работал buildreq, false positive'ил всякие кривые тесты на
> фортран в configure: http://lists.altlinux.org/pipermail/devel/2004-December/1094...
> :)

Я тогда в мандриве сидел, был новичком и собирал по документации аля howto.

> Не могу согласиться -- себя считаю преимущественно пользователем. (:

Ну а я не считаю. ;) Я уже не новичок, но уровень дальше не кажется мне пользовательским. А у вас уровень сильно выше.

> Необученный пользователь -- он ведь и пользоваться-то подчас толком не умеет, одна
> потеря времени и было бы быстрее на бумаге и калькуляторе...

Ещё раз - смотря чему обучен. Одно дело - прикладной профессиональный софт. Другое - работа с системой или программирование на С.

> Брр, в альте автоматически делается hasher-ом (с кэшированием базовой сборочной системы,
> разумеется).  Быстро, сравнительно дёшево, воспроизводито.

По документации видно, что нужен пакет с зависимостями. А мы как раз говорим от тарболлах, в которых эти зависимости создать нужно. ;)

> С этим спору нет, но о том и говорил -- что создавался
> он для _другой_ цели (которую выполняет), а в качестве _побочного_ эффекта
> -- возможно, совсем не предполагавшегося закладывавшими правила -- получился ещё и
> такой :)

А я говорил, что было бы здорово, если бы хорошая организация такого типа хранилица была бы не ручной работой. ;)

>>> Довольно-таки; и над ней постоянно работают в плане улучшения.
>> А какие названия программ?
> buildreq, sisyphus_check, hasher, qa-robot, gear/girar/girar-builder, jppimport, fcimport
> (приблизительно по возрасту)
> Обсуждения можно поискать по слову incominger.

Спасибо.


> Наличие в нём достаточного для этого количества метаинформации в пригодном к автоматическому
> извлечению виде.  Это необходимое, но не достаточное условие.

Метаинформации где? В начальных файлах configure и makefile или ещё где-то?

>>> Поэтому и удивился, когда Вы их назвали спецификацией -- вот и попытался
>>> сообразить, какие из виденных более-менее в ту сторону...
>> А комментарии не спецификация? Типы входных данных, типы выходных, исключения. Мало?
> Конечно, мало.  Это описание фронта и тыла слона, но не его
> состава и жизнедеятельности.

А состав и жизнедеятельность, по идее, должны следовать из теории, как это в математике делается, в тех же CAS или экспертных системах. В программировании её нет, но она возможна. К примеру, существуют общие решения, на основе которых генерируются частные. Дедукция.


> По большей части вообще по тексту, а что?  

Но к этому тексту прилагалась картинка, правда? Без которой изучение только текста было бы много сложнее. И то, текст нужен и как замена невозможной визуализации на бумаге. Той же анимации.

> По фотографии было
> бы хуже, чем по схематическому рисунку;

А я о принципиальных схемах - схематических рисунках и говорю. Фотография, конечно, слишком много деталей содержит.

> а и ему, возможно, предпочёл
> бы граф для утряски понимания взаимодействий.  

Для _утряски_, а не первичного ознакомления и понимания.

>Из смежного -- попробуйте
> представить себе цикл Кребса "по монтажной схеме". :)

Попробуйте заменить там структурные формулы названиями веществ, и понимаемость резко замедлится. Добавьте интерактивности, и скорость освоения возрастёт.


Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "автопакетирование тарболов"  +/
Сообщение от Michael Shigorin email(ok) on 17-Апр-12, 23:12 
> Это здорово, но для linux были бы гораздо более полезны другие системы.
> По автоматизированным сборке и администрированию на уровне пользователя, например.

Так сами ж говорите, что это уже не совсем пользователь -- а сборщик и администратор.  Мне удаётся отделываться тем, что буржуи порой обзывают wearing $that hat -- когда всё-таки надо что-то собрать или уадминить, приходится напяливать соответствующую шляпу и орудовать.  А так -- юзер, просто юзер :)  Вот, vimperator/pentadactyl "не осилил", посмотрев и пощупав (и сидя в vim).

> Ещё раз - смотря чему обучен.

Именно.  И если обучиться собирать какие-то сильно нишевые пакеты быстрее, чем ждать других -- то может иметь смысл освоить.  Сильно благодарен Владимиру Бормотову (тогда из Black Cat Linux team), помогшему верно оценить страшность конкретно этих горшков.

> По документации видно, что нужен пакет с зависимостями. А мы как раз
> говорим от тарболлах, в которых эти зависимости создать нужно. ;)

А, ну в этом плане да.  Я пару сообщений из треда переслал viy@altlinux, который озвучивал планы заняться именно этим вопросом (для распространённых частных случаев).

> А я говорил, что было бы здорово, если бы хорошая организация такого
> типа хранилица была бы не ручной работой. ;)

Думаю, нереально.  Можно добиваться двух вещей:
- большей полезности уже вложенной работы;
- меньшей работы для той же полезности.

>> Наличие в нём достаточного для этого количества метаинформации в пригодном
>> к автоматическому извлечению виде.  Это необходимое, но не достаточное условие.
> Метаинформации где? В начальных файлах configure и makefile или ещё где-то?

В том числе, но необязательно: библиотеки могут быть полезными за счёт dlopen(), картинки тем могут быть нужными для штатного отображения UI, с какими-то конкретными версиями libdb4 могут быть известны развалы базы... вещи из README, которые автоматически не всегда вообще отразишь, потому и недостаточно такого условия.

*.lsm для метаинформации, предназначенной для человека, можно было бы попытаться либо расширить, либо дополнить в рамках отдельного файла и набора договоренностей а-ля LSB/fd.o с тем, чтобы более надёжно получать это самое автоматическое извлечение.

> А состав и жизнедеятельность, по идее, должны следовать из теории, как это
> в математике делается, в тех же CAS или экспертных системах. В
> программировании её нет, но она возможна. К примеру, существуют общие решения,
> на основе которых генерируются частные. Дедукция.

Общие более дороги, хотя нередко и более осмысленны в долгосрочном плане.

>> По большей части вообще по тексту, а что?
> Но к этому тексту прилагалась картинка, правда? Без которой изучение только
> текста было бы много сложнее. И то, текст нужен и как замена
> невозможной визуализации на бумаге. Той же анимации.

Не-не-не, текст без картинки ещё бы воспринял, а вот анимация вместо текста совсем не годится: это скорее впечатление, чем понимание. [...]

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "автопакетирование тарболов"  +/
Сообщение от tmp (ok) on 18-Апр-12, 01:07 
> Так сами ж говорите, что это уже не совсем пользователь -- а
> сборщик и администратор.  

Это если вручную админить и собирать. Всё-таки, запуск checkinstall не требует квалификации  и особого чтения документации.

>А так -- юзер, просто юзер :)

И работаете, наверное, не в области IT.

> Именно.  И если обучиться собирать какие-то сильно нишевые пакеты быстрее, чем
> ждать других -- то может иметь смысл освоить.  

Часто нужны универсальные. Скажем, замена swiftweasel. Или mplayer пересобрать. Здесь широкие знания нужны.

> Думаю, нереально.  Можно добиваться двух вещей:
> - большей полезности уже вложенной работы;
> - меньшей работы для той же полезности.

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

> В том числе, но необязательно: библиотеки могут быть полезными за счёт dlopen(),
> картинки тем могут быть нужными для штатного отображения UI, с какими-то
> конкретными версиями libdb4 могут быть известны развалы базы... вещи из README,
> которые автоматически не всегда вообще отразишь, потому и недостаточно такого условия.
> *.lsm для метаинформации, предназначенной для человека, можно было бы попытаться либо расширить,
> либо дополнить в рамках отдельного файла и набора договоренностей а-ля LSB/fd.o
> с тем, чтобы более надёжно получать это самое автоматическое извлечение.

Понятно.

> Общие более дороги, хотя нередко и более осмысленны в долгосрочном плане.

Общие для создания частных.

> Не-не-не, текст без картинки ещё бы воспринял, а вот анимация вместо текста
> совсем не годится: это скорее впечатление, чем понимание. [...]

В зависимости от того, кто что понимает под пониманием. Если под пониманием понимать построение в голове визуальной модели явления, то проще её, модель, увидеть, чем про неё прочитать. Не зря говорят, что лучше один раз увидеть, чем сто раз услышать.  А если понимание - построение языковой модели, то и чтения достаточно. Но тогда man китайская комната.


Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "автопакетирование тарболов"  +/
Сообщение от Michael Shigorin email(ok) on 18-Апр-12, 02:00 
> Часто нужны универсальные. Скажем, замена swiftweasel. Или mplayer пересобрать.
> Здесь широкие знания нужны.

Вот и не лезу...

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

И то спасибо за обсуждение.

>> Общие более дороги, хотя нередко и более осмысленны в долгосрочном плане.
> Общие для создания частных.

Ой, я своё поделие mkimage-profiles уж второй год пилю...

>> Не-не-не, текст без картинки ещё бы воспринял, а вот анимация вместо текста
>> совсем не годится: это скорее впечатление, чем понимание. [...]
> В зависимости от того, кто что понимает под пониманием.

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

> Но тогда man китайская комната.

Не слышал, почитал; полагаю, у Сирла ошибка в четвёртой аксиоме.  Под фонарём искать грустно...

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

9. "автопакетирование тарболов"  +/
Сообщение от tmp (ok) on 18-Апр-12, 03:35 
> Вот и не лезу...

А я лазил. Ибо нужно было. И обжигался.

> И то спасибо за обсуждение.

Какое же это обсуждение? Так, упоминание при флейме.

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

Это определение не по устройству, а по поведению. Зная устройство, можно узнать поведение. Зная поведение, нельзя узнать устройство.

>> Но тогда man китайская комната.
> Не слышал, почитал; полагаю, у Сирла ошибка в четвёртой аксиоме.  

Возможно, она не всегда верна. Скажем, http://www.langust.ru/review/lang_h02.shtml#02_01 , http://www.langust.ru/review/lang_h02.shtml#02_04

Ну и НЛП есть, а вот образного уже вроде нет.


Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

10. "автопакетирование тарболов"  +/
Сообщение от Nikola2387 (ok) on 21-Апр-12, 01:07 
>[оверквотинг удален]
> Помилуйте, да там тридцать или сколько уже лет утряхивают базовые-расширенные-перловые
> и всякие corner cases.  Это мощный хак, но никакой строгой
> семантикой там и близко не пахнет, IMHO.
>>> Вообще-то нет.  Например, orbitz.com не только для программистов, но без глубоких
>>> макросов вряд ли работал бы так же хорошо.
>> Так макросы по сути тот же самый императивный высокоуровневый код.
> На орбитзах не так давно работали лисповые макросы четвёртого порядка, насколько знаю.
> :)
>> Принципы хорошо познаются в динамике и визуализации. В моделях.
> К слову о том же graphviz: http://fly.osdn.org.ua/~mike/img/m-p/targets_syslinux.png

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2022 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру