* [devel] hasher is lacking black box properties @ 2011-03-02 15:28 Igor Vlasenko 2011-03-02 23:54 ` Dmitry V. Levin 0 siblings, 1 reply; 3+ messages in thread From: Igor Vlasenko @ 2011-03-02 15:28 UTC (permalink / raw) To: devel Господа, давно уже столкнулся с проблемой скриптования работы с hasher, из за которой многие мои скрипты приватные, так как не будут работать в общем случае (в произвольном окружении). наш hasher не является черным ящиком: вход у него есть, и скрипт может подать туда что-нибудь, а вот описания выхода ему не хватает -- chroot, user_a, user_b, repo_bin, repo_src и многое другое, описывающее то, что на выходе, зависит и от настроек hasher+hasher_priv(~/.hasher и др.) и от дополнительных опций, проходящих через скрипт от пользователя к hasher'у. И узнать эти значения сейчас скрипт не может без тайного знания внутренностей hasher. Т.е. сейчас наш hasher, к сожалению, не черный ящик. Это поправить легко, надо только добавить к нему интерфейс описания того, что на выходе. Мое предложение -- опция --reportdir=/path/to/reportdir к hsh, и, возможно, другим утилитам. отчеты будут локальными: каждый полезный кусок кода может проверить, нужен ли отчет if [ -n "$hasher_reportdir" ]; then ... fi и отчитаться в папке reportdir в свой отдельный файл. т.е. формат отчета -- папка с файлами, каждый файл либо список (srpms written, rpms written, например) либо список значений переменных (пар ключ-значение). Т.е. предлагаю обсудить, как будет выглядеть такой интерфейс, если Дмитрий согласится, то написать и я могу. Главное, чтобы он появился в hasher. -- Dr. Igor Vlasenko -------------------- Topology Department Institute of Math Kiev, Ukraine ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [devel] hasher is lacking black box properties 2011-03-02 15:28 [devel] hasher is lacking black box properties Igor Vlasenko @ 2011-03-02 23:54 ` Dmitry V. Levin 2011-03-03 20:03 ` Igor Vlasenko 0 siblings, 1 reply; 3+ messages in thread From: Dmitry V. Levin @ 2011-03-02 23:54 UTC (permalink / raw) To: ALT Devel discussion list [-- Attachment #1: Type: text/plain, Size: 981 bytes --] On Wed, Mar 02, 2011 at 05:28:57PM +0200, Igor Vlasenko wrote: > наш hasher не является черным ящиком: вход у него есть, > и скрипт может подать туда что-нибудь, > а вот описания выхода ему не хватает -- > > chroot, user_a, user_b, repo_bin, repo_src > и многое другое, описывающее то, что на выходе, > зависит и от настроек hasher+hasher_priv(~/.hasher и др.) > и от дополнительных опций, проходящих через скрипт > от пользователя к hasher'у. > > И узнать эти значения сейчас скрипт не может > без тайного знания внутренностей hasher. Т.е. сейчас > наш hasher, к сожалению, не черный ящик. > > Это поправить легко, надо только добавить к нему интерфейс > описания того, что на выходе. > > Мое предложение -- опция --reportdir=/path/to/reportdir > к hsh, и, возможно, другим утилитам. Мне кажется, что и одного файла было бы достаточно, чтобы рассказать обо всем, что может быть интересно. Если нет, то просьба привести контрпример. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [devel] hasher is lacking black box properties 2011-03-02 23:54 ` Dmitry V. Levin @ 2011-03-03 20:03 ` Igor Vlasenko 0 siblings, 0 replies; 3+ messages in thread From: Igor Vlasenko @ 2011-03-03 20:03 UTC (permalink / raw) To: ALT Linux Team development discussions On Thu, Mar 03, 2011 at 02:54:46AM +0300, Dmitry V. Levin wrote: > On Wed, Mar 02, 2011 at 05:28:57PM +0200, Igor Vlasenko wrote: > > наш hasher не является черным ящиком: вход у него есть, > > и скрипт может подать туда что-нибудь, > > а вот описания выхода ему не хватает -- [...] > > Это поправить легко, надо только добавить к нему интерфейс > > описания того, что на выходе. > > > > Мое предложение -- опция --reportdir=/path/to/reportdir > > к hsh, и, возможно, другим утилитам. > Мне кажется, что и одного файла было бы достаточно, чтобы рассказать > обо всем, что может быть интересно. eсли давать вредные советы, то да, один большой файл, и еще желательно в xml, чтобы был полный ЫнтЫрпрайз :) Сходу, как правило, в голову лезут быстрые неправильные решения. Я не вас критикую, я себя критикую -- в баге #, если вы обратили на него внимание, я вообще предлагал вам утилиту hsh-env. Но когда я ее написал, то увидел, что и реализация уродлива, и, что еще хуже, уродливо ее использование в скриптах из-за необходимости проверять код завершения. Немного остыв, подумал о --reportfile=file. > Если нет, то просьба привести контрпример. Я тогда как раз себе и привел контрпример -- в отчете нужны разные денные -- списки (собранных пакетов, напимер) и переменные. распишу на этом примере, какие видятся недостатки. отчет нужен для использования в скриптах, в т.ч. в shell скриптах. Поэтому его формат должен быть дружественным к скриптам, по этой причине xml, ini, conf не желательны. Но в отчете должны быть разнородные данные. списки файлов и значения переменных. Можно, конечно, извратиться, например, завернуть список файлов в переменную. Но зачем извращаться, при чем недружественно к скрипту, которому придется ее разворачивать? Можно попытаться все завернуть в один файл, но вот при попытке это все развернуть в скрипте пользователя вылезет куча подводных камней с разделителями, кавычками, квотированием и максимальной длинной строк. Логичнее было бы отделить мухи от котлет и хранить хорошие списки как текстовые списки, плохие списки как null-terminated string lists, значения переменных - как угодно, но в жестко описанном формате: например, <<variable_name=value.. без кавычек и экранирования, без пробелов вокруг разделителя "=", для получения значения переменной воспользуйтесь стандартной grep/sed или awk конструкцией>> но для этого их придется развести по разным файлам, отсюда и каталог отчета. И не будет проблем с расширяемостью отчета -- старые файлы будут следовать старым соглашениям, а не так, что пришлось добавить кавычки или экранирование и все старые скрипты сломались. Т.е. я считаю, что формат с каталогом отчета гораздо дружественнее к скриптам, ради которых это все и затевается. человеку с головой хватит и |& tee log в конце. -- Dr. Igor Vlasenko -------------------- Topology Department Institute of Math Kiev, Ukraine ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-03-03 20:03 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-03-02 15:28 [devel] hasher is lacking black box properties Igor Vlasenko 2011-03-02 23:54 ` Dmitry V. Levin 2011-03-03 20:03 ` Igor Vlasenko
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git