* [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