26482 2011-10-20 18:53:41 +0400 [patch] add gear-update --post-update-script option 2011-11-02 15:49:12 +0400 1 1 4 Development Sisyphus gear unstable all Linux NEW http://git.altlinux.org/people/viy/packages/?p=gear.git;a=commit;h=6b3306fa990ce45447cabb0ddc3bbd12e3bf9e46 P3 enhancement --- 1 viy ldv glebfm ldv legion placeholder qa-sisyphus oldest_to_newest 126401 0 viy 2011-10-20 18:53:41 +0400 нужно чтобы обрабатывать импорт __до__ git add (в конкретном случае, разжать некоторые вложенные архивы) пример реализации (тестирован, работает) http://git.altlinux.org/people/viy/packages/?p=gear.git;a=commit;h=6b3306fa990ce45447cabb0ddc3bbd12e3bf9e46 126402 1 legion 2011-10-20 19:11:54 +0400 Мне кажется, что правильнее сделать так чтобы gear-update сам разжимал вложенные архивы. То что вы предлагаете больше похоже на быстрый хак. 126404 2 viy 2011-10-20 20:06:32 +0400 > Мне кажется, что правильнее сделать так чтобы gear-update сам разжимал > вложенные архивы. кому-то это наоборот, нежелательное поведение, если он уже их держит в сжатом виде. кроме того, у скрипта может быть и другое полезное применение. 126406 3 viy 2011-10-20 20:49:21 +0400 (В ответ на комментарий №2) > > Мне кажется, что правильнее сделать так чтобы gear-update сам разжимал > > вложенные архивы. > кому-то это наоборот, нежелательное поведение, если он уже их держит в сжатом > виде. > > кроме того, у скрипта может быть и другое полезное применение. т.е. опция для разжатия вложенных архивов и опция запуска скрипта друг другу не мешают, их можно реализовать независимо. Это разная функциональность, вообще говоря. 126414 4 legion 2011-10-21 01:15:49 +0400 Лично я не вижу смысла в этом патче т.к. то как оно сейчас реализовано проще выполнить gear-update несколько раз для необходимых архивов внутри. Что экономит этот патч ? один вызов git-add ? 126416 5 viy 2011-10-21 02:22:16 +0400 (В ответ на комментарий №4) > Лично я не вижу смысла в этом патче т.к. то как оно сейчас реализовано проще > выполнить gear-update несколько раз для необходимых архивов внутри. скажем так, там несколько сот .ppd.gz файлов для разных моделей принтеров. их я разжимаю до просто ppd, так мне легче отслеживать изменения. > Что экономит этот патч ? один вызов git-add ? как видим, гораздо больше, чем один вызов git-add. 126417 6 legion 2011-10-21 02:31:38 +0400 Для этой задачи не нужно патчить gear-update. Последовательность gear-update; find -name '*.ppd.gz' |xargs -r gunzip; git add ... будет эффективнее. 126419 7 viy 2011-10-21 02:57:45 +0400 (В ответ на комментарий №6) > Для этой задачи не нужно патчить gear-update. Последовательность > > gear-update; find -name '*.ppd.gz' |xargs -r gunzip; git add ... > будет эффективнее. gear-update уже сделал git add на *.ppd.gz файлы. Если выполнять операции после gear-update, то дополнительно их придется удалить из индекса и вызвать git gc. проще сразу обойтись без gear-update :( Скрипт становится намного проще и понятнее, если не производит манипуляций с индексом. В чем проблема иметь в gear-update дополнительную опцию? 126420 8 viy 2011-10-21 02:58:35 +0400 если не нравится название опции, можно поменять на любоее другое по вкусу. мне без разницы. 126421 9 legion 2011-10-21 03:12:27 +0400 Операции над индексом не обязательно производить т.к. сжатых файлов не будет. Следующий за gear-update git-commit закоммитит правильные файлы. Я считаю саму идею встраивания произвольного кода в gear-update хаком... к тому же ради экономии на git-add. Эта утилита задумывалась для того, чтобы обновлять часть дерева из файла архива. Дополнительные танцы над новыми данными она не производит. Не нужно превращать утилиту в комбайн к тому же с внешними обработчиками. Если Дима считает нужным, то пусть вносит подобные изменения, но лично я против. 126427 10 viy 2011-10-21 09:39:23 +0400 (В ответ на комментарий №9) > Операции над индексом не обязательно производить т.к. сжатых файлов не будет. > Следующий за gear-update git-commit закоммитит правильные файлы. но в индексе останется мусор # deleted: хххх который придется вычищать :( > Не нужно превращать утилиту в комбайн к тому же с внешними обработчиками. Если утилита позиционируется как стандартная дистрибутивная, то она и должна быть комбайном, который поддерживает возможности, которые автору 100 лет в обед не нужны, но нужны другим людям. Иначе ей место в другом пакете, в legion-utils. > Если Дима считает нужным, то пусть вносит подобные изменения, но лично я > против. :( 126430 11 legion 2011-10-21 11:08:13 +0400 (В ответ на комментарий №10) > # deleted: хххх > который придется вычищать :( Это можно вычищать лишь для эстетики. > Если утилита позиционируется как стандартная дистрибутивная, то она и должна > быть комбайном, Нет. 126725 12 ldv 2011-11-02 05:52:53 +0400 (In reply to comment #9) > Я считаю саму идею встраивания произвольного кода в gear-update хаком... Насколько я понимаю, в сам gear-update никто не предлагает встраивать запуск произвольного кода. > к тому же ради экономии на git-add. Если после запуска gear-update дерево надо подчищать, то проще обновлять дерево вручную. Все удобство от использования gear-update образуется в результате того, что у этой утилиты простой интерфейс и она не оставляет за собой хвостов. > Эта утилита задумывалась для того, чтобы обновлять > часть дерева из файла архива. Дополнительные танцы над новыми данными она не > производит. Вопрос в том, как определять понятие "обновлять часть дерева". Например, если внутри архива есть другой архив, то кто-то может сказать, что этот внутренний архив тоже надо распаковать. Возможно, gear-update стоит обучить работать в режиме --deep=N, где N это глубина рекурсии по расжатию и распаковке. > Не нужно превращать утилиту в комбайн к тому же с внешними > обработчиками. Я не вижу во внешних обработчиках ничего заведомо плохого. Если от этого интерфейса кому-то может быть польза, а сам по себе он ничего не портит, то зачем от него отказываться? Кстати, я придумал еще один пример кастомного обработчика, который в принципе может когда-нибудь понадобиться: это удаление нежелательных файлов по какому-нибудь критерию (файлы с недопустимыми условиями распространения, бекап-файлы, скомпилированные файлы, и т.п.) Было бы логично, если бы кастомный обработчик находился в том же репозитории, что и обновляемые архивы, иначе будет непонятно, каким образом эти архивы были обновлены. К сожалению, это требование невозможно сделать обязательным (просто потому, что кастомный обработчик все равно выполняет произвольный код из произвольного места). (In reply to comment #8) > если не нравится название опции, можно поменять на любоее другое по вкусу. > мне без разницы. Мне вообще кажется, что это было бы удобнее настраивать через $GIT_DIR/config, см. раздел CONFIGURATION в gear-import(1). Тогда кастомные обработчики естественным образом (через gear-update) встроились бы и в gear-import. 126739 13 legion 2011-11-02 14:18:23 +0400 (В ответ на комментарий №12) > Насколько я понимаю, в сам gear-update никто не предлагает встраивать запуск > произвольного кода. В данном случае я имел в виду запуск произвольной программы. > Если после запуска gear-update дерево надо подчищать, то проще обновлять дерево > вручную. Все удобство от использования gear-update образуется в результате > того, что у этой утилиты простой интерфейс и она не оставляет за собой хвостов. Я проверил результат выполнения gear-update несколько раз на одном и том же дереве (второй запуск был разумеется с --force) и никаких deleted хвотов не обнаружил. Таким образом, рекурсивно распаковывать архивы можно и эстетика не страдает. Проблема только в том, что разжимая архив внутри дерева нет возможности его сразу удалить после распаковки. Эту проблему можно решить. > Возможно, gear-update стоит обучить работать в режиме --deep=N, где N это > глубина рекурсии по расжатию и распаковке. Примерно эту идею я выдвигал в #1 :) Но после от неё отказался т.к. пользователь не обязательно хочет распаковывать все архивы внутри N. Эту ситуацию придётся разрешать дополнительными телодвижениями в виде шаблонов имён или ещё как-то. На мой взгляд, проще и правильнее предоставить пользователю возможность запускать gear-update внутри дерева. Тогда пользователь сможет рекурсивно разжать только нужные архивы. > Я не вижу во внешних обработчиках ничего заведомо плохого. Если от этого > интерфейса кому-то может быть польза, а сам по себе он ничего не портит, то > зачем от него отказываться? Обоснование такого кастомного обработчика не достаточное в этой баге. > Кстати, я придумал еще один пример кастомного обработчика, который в принципе > может когда-нибудь понадобиться: это удаление нежелательных файлов по > какому-нибудь критерию (файлы с недопустимыми условиями распространения, > бекап-файлы, скомпилированные файлы, и т.п.) А вот это уже более конкретный use-case. Почему тебя не устраивают .gitignore или .git/info/exclude ? 126740 14 ldv 2011-11-02 14:31:42 +0400 (In reply to comment #13) > Я проверил результат выполнения gear-update несколько раз на одном и том же > дереве (второй запуск был разумеется с --force) и никаких deleted хвотов не > обнаружил. Таким образом, рекурсивно распаковывать архивы можно и эстетика не > страдает. Конечно, можно, но сейчас есть два ограничения. > Проблема только в том, что разжимая архив внутри дерева нет возможности его > сразу удалить после распаковки. > Эту проблему можно решить. Это первое ограничение. > На мой взгляд, проще и правильнее предоставить пользователю возможность > запускать gear-update внутри дерева. Тогда пользователь сможет рекурсивно > разжать только нужные архивы. Необходимость запуска gear-update более одного раза для полного обновления дерева из одного тарболла - это другое ограничение, если иметь в виду gear-import, который запускает gear-update ровно один раз. > > Кстати, я придумал еще один пример кастомного обработчика, который в принципе > > может когда-нибудь понадобиться: это удаление нежелательных файлов по > > какому-нибудь критерию (файлы с недопустимыми условиями распространения, > > бекап-файлы, скомпилированные файлы, и т.п.) > > А вот это уже более конкретный use-case. > Почему тебя не устраивают .gitignore или .git/info/exclude ? Это, как видно, менее конкретный и менее удачный пример; для его реализации механизма gitignore(5) должно быть достаточно. 126741 15 legion 2011-11-02 14:46:34 +0400 (В ответ на комментарий №14) > Это, как видно, менее конкретный и менее удачный пример; для его реализации > механизма gitignore(5) должно быть достаточно. Кстати: $ gear-update --help |grep exclude= --exclude=PATTERN exclude files matching posix-egrep regular expression PATTERN; 126742 16 legion 2011-11-02 14:54:20 +0400 (В ответ на комментарий №14) > > Проблема только в том, что разжимая архив внутри дерева нет возможности его > > сразу удалить после распаковки. > > Эту проблему можно решить. > > Это первое ограничение. Это исправим. В любом случае это полезная возможность. > Необходимость запуска gear-update более одного раза для полного обновления > дерева из одного тарболла - это другое ограничение, Я не считаю это ограничением. Это поведение идентично tar/zip/gzip, которые не пытаются распаковать архивы внутри архива. > если иметь в виду > gear-import, который запускает gear-update ровно один раз. Это "ограничение" тоже можно попробовать решить. Устранение подобных ограничений более конструктивная задача за которую стоит браться. 126745 17 ldv 2011-11-02 15:09:45 +0400 (In reply to comment #16) > (В ответ на комментарий №14) > > > Проблема только в том, что разжимая архив внутри дерева нет возможности его > > > сразу удалить после распаковки. > > > Эту проблему можно решить. > > > > Это первое ограничение. > > Это исправим. В любом случае это полезная возможность. Договорились. > > Необходимость запуска gear-update более одного раза для полного обновления > > дерева из одного тарболла - это другое ограничение, > > Я не считаю это ограничением. Это поведение идентично tar/zip/gzip, которые не > пытаются распаковать архивы внутри архива. > > > если иметь в виду > > gear-import, который запускает gear-update ровно один раз. > > Это "ограничение" тоже можно попробовать решить. > > Устранение подобных ограничений более конструктивная задача за которую стоит > браться. Если рассматривать gear-update как простой низкоуровневый инструмент, тогда алгоритм настраиваемого итерационного запуска gear-update должен быть реализован за его пределами. Поскольку gear-import использует gear-update, можно предложить реализовать этот алгоритм в gear-import. 126749 18 viy 2011-11-02 15:21:39 +0400 (В ответ на комментарий №16) > Устранение подобных ограничений более конструктивная задача за которую стоит > браться. А исходное пожелание по поводу обработчика? 126756 19 legion 2011-11-02 15:47:47 +0400 (В ответ на комментарий №17) > Договорились. Уже в процессе. > Если рассматривать gear-update как простой низкоуровневый инструмент, тогда > алгоритм настраиваемого итерационного запуска gear-update должен быть > реализован за его пределами. Поскольку gear-import использует gear-update, > можно предложить реализовать этот алгоритм в gear-import. Да. Мне это кажется более правильным. 126757 20 legion 2011-11-02 15:49:12 +0400 (В ответ на комментарий №18) > А исходное пожелание по поводу обработчика? Ваша задача должна решаться не обработчиком.