Было бы неплохо добавить к diff в gear-rules возможность указывать exclude каталогам. Мне это нужно для того, что бы в патч не попадал каталог .gear например: diff: v@version@:. . exclude=.gear
Сейчас готовлю релиз с этой возможностью, чтобы предложить (одобрить). Можно посмотреть сейчас в git.altlinux.org/people/imz/packages/gear.git (ветка alt). Пусть только коммиты с тестами не пугают. По сути они, конечно, работают и написаны для большинства случаев. Но остаётся привести в лучший вид. Мне не понравилось, что мы с grenka@ размножили файлы тестов, сейчас хочу дедуплицировать код тестов. Будет полезно не только для diff, но правил типа tar. Пример: diff: v@version@:. . -- . :!.gear tar: v@version@:. -- . :!.gear Используется синтаксис (с магией), понимаемый командами Git с некоторый пор: git cmd ... -- paths.. Из-за ошибки в Git приходится писать не как в примерах (с точкой), а со звёздочкой (только для правил типа tar, а не diff; т.е. ошибка есть в работе git archive, но не git diff): tar: v@version@:. -- * :!.gear Приветствуется ознакомление заинтересованных.
(В ответ на комментарий №1) > Мне не > понравилось, что мы с grenka@ размножили файлы тестов, сейчас хочу > дедуплицировать код тестов. Залей так. Когда разберёмся с кодом тестов, обновим релиз, в чём проблема? "Что сделано не вовремя, сделано понапрасну" (с) Френсис Бэкон
(In reply to comment #2) > (В ответ на комментарий №1) > > Мне не > > понравилось, что мы с grenka@ размножили файлы тестов, сейчас хочу > > дедуплицировать код тестов. > > Залей так. Когда разберёмся с кодом тестов, обновим релиз, в чём проблема? Просто этот пакет кто-то из acl будет смотреть и одобрять. Я уже этим сообщением предложил посмотреть. И в тот момент, когда кто-то будет готов одобрить, можно будет отправить текущее состояние. Пока что переписываю дополнительные тесты с помощью дополнительных функций в том же файле (вызывающих основную), без копирования файла. Частично это сделано, можно увидеть в моих опубликованных коммитах.
Можно будет попробовать в task 210568
(In reply to comment #1) > Сейчас готовлю релиз с этой возможностью, чтобы предложить (одобрить). > > Можно посмотреть сейчас в git.altlinux.org/people/imz/packages/gear.git (ветка > alt). Там специально commit messages в другом стиле выполнены? Некоторые по ширине даже у меня на экране не помещаются.
(In reply to comment #5) > (In reply to comment #1) > > Сейчас готовлю релиз с этой возможностью, чтобы предложить (одобрить). > > > > Можно посмотреть сейчас в git.altlinux.org/people/imz/packages/gear.git (ветка > > alt). > > Там специально commit messages в другом стиле выполнены? > Некоторые по ширине даже у меня на экране не помещаются. Нет, я не обращал внимание. Посмотрю. Пользуясь случаем, хочу рассказать, что на i586 произошла ошибка в задании 210568: gear-update: /usr/src/tmp/run.lcG0esBBa/.git/.work/initial-import.cpio.zst: unrecognized source type: [FAIL] (gear_update_subdir_sub_cpio_zst_cwd)
(In reply to comment #6) > Пользуясь случаем, хочу рассказать, что на i586 произошла ошибка в задании > 210568: > > gear-update: /usr/src/tmp/run.lcG0esBBa/.git/.work/initial-import.cpio.zst: > unrecognized source type: > [FAIL] (gear_update_subdir_sub_cpio_zst_cwd) http://git.altlinux.org/beehive/logs/Sisyphus-i586/archive/2018/0720/success/gear-2.2.0-alt1 http://git.altlinux.org/beehive/logs/Sisyphus-i586/archive/2018/0719/error/gear-2.2.0-alt1.zst http://git.altlinux.org/beehive/logs/Sisyphus-i586/archive/2018/0717/success/gear-2.2.0-alt1.zst ... http://git.altlinux.org/beehive/logs/Sisyphus-i586/archive/2018/0701/success/gear-2.2.0-alt1.zst
(In reply to comment #5) > (In reply to comment #1) > > Сейчас готовлю релиз с этой возможностью, чтобы предложить (одобрить). > > > > Можно посмотреть сейчас в git.altlinux.org/people/imz/packages/gear.git (ветка > > alt). > > Там специально commit messages в другом стиле выполнены? > Некоторые по ширине даже у меня на экране не помещаются. Переписал. Ещё дописываю обновление документации. Есть ли возражения против всего остального? (Пока с этим копался, появилась мысль, что тесты можно было бы покороче записать, с меньшми повторениями, в т.ч. старые, но я не стремлюсь переписать их к ближайшему релизу.)
В коммите "Amend all remaining gear-rules-archive-*.test with tests for magic paths" очень странное выравнивание: добавляются строки, начинающиеся с 8 табов. Ну и вообще читабельность тестов снизилась с "нечитабельно" до "совсем нечитабельно". :)
(In reply to comment #9) > В коммите "Amend all remaining gear-rules-archive-*.test with tests for magic > paths" очень странное выравнивание: добавляются строки, начинающиеся с 8 табов. Поправил, и отправил на сборку. Это уже все изменения с моей стороны на данный момент, больше ничего добавлять перед предложеннымм релизом не планирую по своей задумке. Учту замечания. > Ну и вообще читабельность тестов снизилась с "нечитабельно" до "совсем > нечитабельно". :) Я это тоже вижу, но быстро без переосмысления и перестркутурирования не могу поменять сейчас.
Ping?
Изменения, не связанные с тестами, я посмотрел ещё в июле и они меня устраивают. Изменения тестов я просто не в состоянии прочитать.
Я попробую их вычитать.
(В ответ на комментарий №12) > Изменения, не связанные с тестами, я посмотрел ещё в июле и они меня > устраивают. Дим, я чего-то не заметил и gear стал не posix совместимым проектом ? С каких пор мы начали массивы использовать ? http://git.altlinux.org/people/imz/packages/gear.git?p=gear.git;a=commitdiff;h=d966f99507e46836b6c8be43daf93a9dd67764c7
Я не против предложенных изменений. Я против реализации. Этот проект никогда не использовал башизмы. Я уверен, что эти изменения можно реализовать без их использования.
(В ответ на комментарий №15) > Я не против предложенных изменений. Я против реализации. Этот проект никогда не > использовал башизмы. Я уверен, что эти изменения можно реализовать без их > использования. Я, конечно, понимаю, что вы все такие духовно-продвинутые и лишний пробел в конце строки у вас вызывает эпилептический припадок, я даже готов понять, что 10 строк коммит-мессаджа должны описывать 3 строчки кода. Объясните мне, почему башизмы это плохо? Почему это _НАСТОЛЬКО_ПЛОХО_, чтобы не пропускать довольно необходимое изменение в сборочницу? Ведь решение этой баги позволит не паковать блобы в српм, например, с помощью одной лишь строчки в rules, а не созданием лишней ветви в гите и постоянным мерджем при обновлениях.
(In reply to comment #15) > Я не против предложенных изменений. Я против реализации. Этот проект никогда не > использовал башизмы. Я уверен, что эти изменения можно реализовать без их > использования. Я более-менее спокойно отношусь к требованиям того или иного проекта по стилю или стандарту языка. Не вижу тут особой проблемы. Кстати, в отличие от girar (где мы во внутренней кухне допускаем башизмы) могу понять, что в gear это не очень желательно, потому что пользователи могут быть на разных системах. Тут после прочтения коммента ещё пока не успел переписать. Когда писал, то ли мне казалось, что уже есть используемые башизмы в gear, то ли хотел просто попонятнее, покороче и поточнее выразить задумку и получить отклик.
(В ответ на комментарий №17) > Я более-менее спокойно отношусь к требованиям того или иного проекта по стилю > или стандарту языка. Не вижу тут особой проблемы. Кстати, в отличие от girar > (где мы во внутренней кухне допускаем башизмы) могу понять, что в gear это не > очень желательно, потому что пользователи могут быть на разных системах. Спасибо за понимание. > Когда писал, то ли мне казалось, что уже есть используемые башизмы в gear, то > ли хотел просто попонятнее, покороче и поточнее выразить задумку и получить > отклик. Если они и есть (сходу их не смог найти), то это явно бага. Если вы их видели, то напишите.
(В ответ на комментарий №16) > Я, конечно, понимаю, что вы все такие духовно-продвинутые и лишний пробел в > конце строки у вас вызывает эпилептический припадок, я даже готов понять, что > 10 строк коммит-мессаджа должны описывать 3 строчки кода. Судя по вашему комментарию, вы этого не понимаете. > Объясните мне, почему башизмы это плохо? Вы ограничиваете проект с posix-compatible, до bash-specific. Башизмы хорошы там, где они приняты. В etcnet с ними никто не борется т.к. проект изначально был написан на bash. Нужно поминть, что bashism это определённый диалект шелла. Такой же как zshism. Ваше возмущение можно сравнить с возмущением, что кто-то отвергает zsh-speific код, а он такой локаничный и реализует что-то полезное. Любой такой диалект уменьшает количесто возможных интерпретаторов шелла до одного. Башизмы можно использовать только в bash и даже не все и не во всех версиях баш. > Почему это _НАСТОЛЬКО_ПЛОХО_, чтобы не пропускать довольно необходимое > изменение в сборочницу? Понятие "довольно необходимые" очень относительно. Любое изменение довольно необходимо. Повторю, я совершенно не против предложенного функционала, но я против того как это реализовано. Утрируя я могу сказать, что я также против довольно необходимых изменений c использованием python или ruby в этом проекте. Это моя позиция. Она может отличаться от позиции Димы. P.S. Это оффтопик для этой баги. Если вы хотите это обсудить, то пишите мне лично или в рассылку.
Да согласен с Лёшей - использование расширений bash в именно этом проекте недопустимо. gear может работать без hasher и не на альте. Лучше эту фичу сохранить. Правда, ему для полного счастья ещё требуется rpm от альта, но это уже немного другой разговор.
*** Bug 35219 has been marked as a duplicate of this bug. ***
Если Ваня этим не занимается, то давайте попросим автора gear добавить эту фичу.
Очень интересная фича. Можно узнать про ее статус?
(In reply to Stanislav Levin from comment #23) > Очень интересная фича. > Можно узнать про ее статус? У меня в целом всё готово было (аз я уже просил approve), только legion@ не хотел видеть там в коде один bashism, а также тестов стало больше и их задание, к сожалению, менее вразумительно стало выглядеть. (По-моему, замечание от ldv@ было.)
Apparently, diff exclude= option was implemented in * Sat Dec 19 2020 Dmitry V. Levin <ldv@altlinux> 2.4.0-alt1 - Added "exclude=" option to "diff" directive (by Vladimir D. Seleznev, Alexey Gladkov, and me).
Спасибо, а это будет работать для всех stable веток ?
(In reply to Anton Farygin from comment #26) > Спасибо, а это будет работать для всех stable веток ? Тестирование на сборочнице пока проходит успешно.
Спасибо. Начал пользоваться и наткнулся на то, что у меня есть один случай, когда эта опция была бы полезна для директивы tar Насколько сложно будет её добавить ? Стоит ли по этому поводу заводить отдельный FR ?
(In reply to Anton Farygin from comment #28) > Спасибо. Начал пользоваться и наткнулся на то, что у меня есть один случай, > когда эта опция была бы полезна для директивы tar > > Насколько сложно будет её добавить ? Стоит ли по этому поводу заводить > отдельный FR ? Концептуально exclude для архивов (tar, zip) ничему не противоречит, сложность реализации аналогична exclude для dif, на самом деле даже проще, потому что можно использовать реализацию exclude для diff в качестве примера. Для отслеживания лучше завести отдельный FR.
(Ответ для Anton Farygin на комментарий #28) > Спасибо. Начал пользоваться и наткнулся на то, что у меня есть один случай, > когда эта опция была бы полезна для директивы tar > > Насколько сложно будет её добавить ? Стоит ли по этому поводу заводить > отдельный FR ? Не сложно. Лучше открой новый баг и повесь на меня.
