Bug 26482

Summary: [patch] add gear-update --post-update-script option
Product: Sisyphus Reporter: viy <viy>
Component: gearAssignee: Dmitry V. Levin <ldv>
Status: NEW --- QA Contact: qa-sisyphus
Severity: enhancement    
Priority: P3 CC: glebfm, ldv, legion, placeholder
Version: unstable   
Hardware: all   
OS: Linux   
URL: http://git.altlinux.org/people/viy/packages/?p=gear.git;a=commit;h=6b3306fa990ce45447cabb0ddc3bbd12e3bf9e46

Description viy 2011-10-20 18:53:41 MSK
нужно чтобы обрабатывать импорт __до__ git add
(в конкретном случае, разжать некоторые вложенные архивы)

пример реализации (тестирован, работает)
http://git.altlinux.org/people/viy/packages/?p=gear.git;a=commit;h=6b3306fa990ce45447cabb0ddc3bbd12e3bf9e46
Comment 1 Alexey Gladkov 2011-10-20 19:11:54 MSK
Мне кажется, что правильнее сделать так чтобы gear-update сам разжимал вложенные архивы. То что вы предлагаете больше похоже на быстрый хак.
Comment 2 viy 2011-10-20 20:06:32 MSK
> Мне кажется, что правильнее сделать так чтобы gear-update сам разжимал
> вложенные архивы. 
кому-то это наоборот, нежелательное поведение, если он уже их держит в сжатом виде.

кроме того, у скрипта может быть и другое полезное применение.
Comment 3 viy 2011-10-20 20:49:21 MSK
(В ответ на комментарий №2)
> > Мне кажется, что правильнее сделать так чтобы gear-update сам разжимал
> > вложенные архивы. 
> кому-то это наоборот, нежелательное поведение, если он уже их держит в сжатом
> виде.
> 
> кроме того, у скрипта может быть и другое полезное применение.

т.е. опция для разжатия вложенных архивов и опция запуска скрипта друг другу не мешают, их можно реализовать независимо. Это разная функциональность, вообще говоря.
Comment 4 Alexey Gladkov 2011-10-21 01:15:49 MSK
Лично я не вижу смысла в этом патче т.к. то как оно сейчас реализовано проще выполнить gear-update несколько раз для необходимых архивов внутри.

Что экономит этот патч ? один вызов git-add ?
Comment 5 viy 2011-10-21 02:22:16 MSK
(В ответ на комментарий №4)
> Лично я не вижу смысла в этом патче т.к. то как оно сейчас реализовано проще
> выполнить gear-update несколько раз для необходимых архивов внутри.

скажем так, там несколько сот .ppd.gz файлов для разных моделей принтеров.
их я разжимаю до просто ppd, так мне легче отслеживать изменения.

> Что экономит этот патч ? один вызов git-add ?
как видим, гораздо больше, чем один вызов git-add.
Comment 6 Alexey Gladkov 2011-10-21 02:31:38 MSK
Для этой задачи не нужно патчить gear-update. Последовательность

gear-update; find -name '*.ppd.gz' |xargs -r gunzip; git add ...

будет эффективнее.
Comment 7 viy 2011-10-21 02:57:45 MSK
(В ответ на комментарий №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 дополнительную опцию?
Comment 8 viy 2011-10-21 02:58:35 MSK
если не нравится название опции, можно поменять на любоее другое по вкусу.
мне без разницы.
Comment 9 Alexey Gladkov 2011-10-21 03:12:27 MSK
Операции над индексом не обязательно производить т.к. сжатых файлов не будет. Следующий за gear-update git-commit закоммитит правильные файлы.

Я считаю саму идею встраивания произвольного кода в gear-update хаком... к тому же ради экономии на git-add. Эта утилита задумывалась для того, чтобы обновлять часть дерева из файла архива. Дополнительные танцы над новыми данными она не производит. Не нужно превращать утилиту в комбайн к тому же с внешними обработчиками.

Если Дима считает нужным, то пусть вносит подобные изменения, но лично я против.
Comment 10 viy 2011-10-21 09:39:23 MSK
(В ответ на комментарий №9)
> Операции над индексом не обязательно производить т.к. сжатых файлов не будет.
> Следующий за gear-update git-commit закоммитит правильные файлы.
но в индексе останется мусор 
#       deleted:    хххх
который придется вычищать :(

> Не нужно превращать утилиту в комбайн к тому же с внешними обработчиками.

Если утилита позиционируется как стандартная дистрибутивная, то она и должна
быть комбайном, который поддерживает возможности, которые автору 100 лет в обед не нужны, но нужны другим людям.

Иначе ей место в другом пакете, в legion-utils.

> Если Дима считает нужным, то пусть вносит подобные изменения, но лично я
> против.

:(
Comment 11 Alexey Gladkov 2011-10-21 11:08:13 MSK
(В ответ на комментарий №10)
> #       deleted:    хххх
> который придется вычищать :(

Это можно вычищать лишь для эстетики.

> Если утилита позиционируется как стандартная дистрибутивная, то она и должна
> быть комбайном,

Нет.
Comment 12 Dmitry V. Levin 2011-11-02 05:52:53 MSK
(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.
Comment 13 Alexey Gladkov 2011-11-02 14:18:23 MSK
(В ответ на комментарий №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 ?
Comment 14 Dmitry V. Levin 2011-11-02 14:31:42 MSK
(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) должно быть достаточно.
Comment 15 Alexey Gladkov 2011-11-02 14:46:34 MSK
(В ответ на комментарий №14)
> Это, как видно, менее конкретный и менее удачный пример; для его реализации
> механизма gitignore(5) должно быть достаточно.

Кстати:

$ gear-update --help |grep exclude=
  --exclude=PATTERN   exclude files matching posix-egrep regular expression PATTERN;
Comment 16 Alexey Gladkov 2011-11-02 14:54:20 MSK
(В ответ на комментарий №14)
> > Проблема только в том, что разжимая архив внутри дерева нет возможности его
> > сразу удалить после распаковки.
> > Эту проблему можно решить.
> 
> Это первое ограничение.

Это исправим. В любом случае это полезная возможность.
 
> Необходимость запуска gear-update более одного раза для полного обновления
> дерева из одного тарболла - это другое ограничение,

Я не считаю это ограничением. Это поведение идентично tar/zip/gzip, которые не пытаются распаковать архивы внутри архива.

> если иметь в виду
> gear-import, который запускает gear-update ровно один раз.

Это "ограничение" тоже можно попробовать решить.

Устранение подобных ограничений более конструктивная задача за которую стоит браться.
Comment 17 Dmitry V. Levin 2011-11-02 15:09:45 MSK
(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.
Comment 18 viy 2011-11-02 15:21:39 MSK
(В ответ на комментарий №16)
> Устранение подобных ограничений более конструктивная задача за которую стоит
> браться.
А исходное пожелание по поводу обработчика?
Comment 19 Alexey Gladkov 2011-11-02 15:47:47 MSK
(В ответ на комментарий №17)
> Договорились.

Уже в процессе.

> Если рассматривать gear-update как простой низкоуровневый инструмент, тогда
> алгоритм настраиваемого итерационного запуска gear-update должен быть
> реализован за его пределами.  Поскольку gear-import использует gear-update,
> можно предложить реализовать этот алгоритм в gear-import.

Да. Мне это кажется более правильным.
Comment 20 Alexey Gladkov 2011-11-02 15:49:12 MSK
(В ответ на комментарий №18)
> А исходное пожелание по поводу обработчика?

Ваша задача должна решаться не обработчиком.