31851 2016-03-02 11:53:15 +0300 add exclude to diff options 2021-03-15 15:28:23 +0300 1 1 4 Development Sisyphus gear unstable all Linux CLOSED FIXED P3 normal --- 1 rider imz boyarsh cas glebfm grenka grenka imz ldv legion nbr placeholder rider slev vseleznv qa-sisyphus oldest_to_newest 155490 0 rider 2016-03-02 11:53:15 +0300 Было бы неплохо добавить к diff в gear-rules возможность указывать exclude каталогам. Мне это нужно для того, что бы в патч не попадал каталог .gear например: diff: v@version@:. . exclude=.gear 172796 1 imz 2018-07-20 08:08:28 +0300 Сейчас готовлю релиз с этой возможностью, чтобы предложить (одобрить). Можно посмотреть сейчас в 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 Приветствуется ознакомление заинтересованных. 172798 2 grenka 2018-07-20 10:04:15 +0300 (В ответ на комментарий №1) > Мне не > понравилось, что мы с grenka@ размножили файлы тестов, сейчас хочу > дедуплицировать код тестов. Залей так. Когда разберёмся с кодом тестов, обновим релиз, в чём проблема? "Что сделано не вовремя, сделано понапрасну" (с) Френсис Бэкон 172799 3 imz 2018-07-20 10:12:49 +0300 (In reply to comment #2) > (В ответ на комментарий №1) > > Мне не > > понравилось, что мы с grenka@ размножили файлы тестов, сейчас хочу > > дедуплицировать код тестов. > > Залей так. Когда разберёмся с кодом тестов, обновим релиз, в чём проблема? Просто этот пакет кто-то из acl будет смотреть и одобрять. Я уже этим сообщением предложил посмотреть. И в тот момент, когда кто-то будет готов одобрить, можно будет отправить текущее состояние. Пока что переписываю дополнительные тесты с помощью дополнительных функций в том же файле (вызывающих основную), без копирования файла. Частично это сделано, можно увидеть в моих опубликованных коммитах. 172811 4 imz 2018-07-20 16:06:57 +0300 Можно будет попробовать в task 210568 172812 5 ldv 2018-07-20 16:19:34 +0300 (In reply to comment #1) > Сейчас готовлю релиз с этой возможностью, чтобы предложить (одобрить). > > Можно посмотреть сейчас в git.altlinux.org/people/imz/packages/gear.git (ветка > alt). Там специально commit messages в другом стиле выполнены? Некоторые по ширине даже у меня на экране не помещаются. 172813 6 imz 2018-07-20 16:29:22 +0300 (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) 172814 7 ldv 2018-07-20 16:44:59 +0300 (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 172817 8 imz 2018-07-20 16:56:14 +0300 (In reply to comment #5) > (In reply to comment #1) > > Сейчас готовлю релиз с этой возможностью, чтобы предложить (одобрить). > > > > Можно посмотреть сейчас в git.altlinux.org/people/imz/packages/gear.git (ветка > > alt). > > Там специально commit messages в другом стиле выполнены? > Некоторые по ширине даже у меня на экране не помещаются. Переписал. Ещё дописываю обновление документации. Есть ли возражения против всего остального? (Пока с этим копался, появилась мысль, что тесты можно было бы покороче записать, с меньшми повторениями, в т.ч. старые, но я не стремлюсь переписать их к ближайшему релизу.) 172821 9 ldv 2018-07-20 20:25:46 +0300 В коммите "Amend all remaining gear-rules-archive-*.test with tests for magic paths" очень странное выравнивание: добавляются строки, начинающиеся с 8 табов. Ну и вообще читабельность тестов снизилась с "нечитабельно" до "совсем нечитабельно". :) 172827 10 imz 2018-07-21 01:07:31 +0300 (In reply to comment #9) > В коммите "Amend all remaining gear-rules-archive-*.test with tests for magic > paths" очень странное выравнивание: добавляются строки, начинающиеся с 8 табов. Поправил, и отправил на сборку. Это уже все изменения с моей стороны на данный момент, больше ничего добавлять перед предложеннымм релизом не планирую по своей задумке. Учту замечания. > Ну и вообще читабельность тестов снизилась с "нечитабельно" до "совсем > нечитабельно". :) Я это тоже вижу, но быстро без переосмысления и перестркутурирования не могу поменять сейчас. 174266 11 grenka 2018-09-18 17:57:27 +0300 Ping? 174267 12 ldv 2018-09-18 20:13:25 +0300 Изменения, не связанные с тестами, я посмотрел ещё в июле и они меня устраивают. Изменения тестов я просто не в состоянии прочитать. 174272 13 legion 2018-09-18 23:34:23 +0300 Я попробую их вычитать. 174312 14 legion 2018-09-19 18:47:23 +0300 (В ответ на комментарий №12) > Изменения, не связанные с тестами, я посмотрел ещё в июле и они меня > устраивают. Дим, я чего-то не заметил и gear стал не posix совместимым проектом ? С каких пор мы начали массивы использовать ? http://git.altlinux.org/people/imz/packages/gear.git?p=gear.git;a=commitdiff;h=d966f99507e46836b6c8be43daf93a9dd67764c7 174632 15 legion 2018-10-01 22:15:03 +0300 Я не против предложенных изменений. Я против реализации. Этот проект никогда не использовал башизмы. Я уверен, что эти изменения можно реализовать без их использования. 174633 16 grenka 2018-10-01 23:14:05 +0300 (В ответ на комментарий №15) > Я не против предложенных изменений. Я против реализации. Этот проект никогда не > использовал башизмы. Я уверен, что эти изменения можно реализовать без их > использования. Я, конечно, понимаю, что вы все такие духовно-продвинутые и лишний пробел в конце строки у вас вызывает эпилептический припадок, я даже готов понять, что 10 строк коммит-мессаджа должны описывать 3 строчки кода. Объясните мне, почему башизмы это плохо? Почему это _НАСТОЛЬКО_ПЛОХО_, чтобы не пропускать довольно необходимое изменение в сборочницу? Ведь решение этой баги позволит не паковать блобы в српм, например, с помощью одной лишь строчки в rules, а не созданием лишней ветви в гите и постоянным мерджем при обновлениях. 174635 17 imz 2018-10-01 23:42:19 +0300 (In reply to comment #15) > Я не против предложенных изменений. Я против реализации. Этот проект никогда не > использовал башизмы. Я уверен, что эти изменения можно реализовать без их > использования. Я более-менее спокойно отношусь к требованиям того или иного проекта по стилю или стандарту языка. Не вижу тут особой проблемы. Кстати, в отличие от girar (где мы во внутренней кухне допускаем башизмы) могу понять, что в gear это не очень желательно, потому что пользователи могут быть на разных системах. Тут после прочтения коммента ещё пока не успел переписать. Когда писал, то ли мне казалось, что уже есть используемые башизмы в gear, то ли хотел просто попонятнее, покороче и поточнее выразить задумку и получить отклик. 174637 18 legion 2018-10-02 02:03:29 +0300 (В ответ на комментарий №17) > Я более-менее спокойно отношусь к требованиям того или иного проекта по стилю > или стандарту языка. Не вижу тут особой проблемы. Кстати, в отличие от girar > (где мы во внутренней кухне допускаем башизмы) могу понять, что в gear это не > очень желательно, потому что пользователи могут быть на разных системах. Спасибо за понимание. > Когда писал, то ли мне казалось, что уже есть используемые башизмы в gear, то > ли хотел просто попонятнее, покороче и поточнее выразить задумку и получить > отклик. Если они и есть (сходу их не смог найти), то это явно бага. Если вы их видели, то напишите. 174638 19 legion 2018-10-02 02:37:49 +0300 (В ответ на комментарий №16) > Я, конечно, понимаю, что вы все такие духовно-продвинутые и лишний пробел в > конце строки у вас вызывает эпилептический припадок, я даже готов понять, что > 10 строк коммит-мессаджа должны описывать 3 строчки кода. Судя по вашему комментарию, вы этого не понимаете. > Объясните мне, почему башизмы это плохо? Вы ограничиваете проект с posix-compatible, до bash-specific. Башизмы хорошы там, где они приняты. В etcnet с ними никто не борется т.к. проект изначально был написан на bash. Нужно поминть, что bashism это определённый диалект шелла. Такой же как zshism. Ваше возмущение можно сравнить с возмущением, что кто-то отвергает zsh-speific код, а он такой локаничный и реализует что-то полезное. Любой такой диалект уменьшает количесто возможных интерпретаторов шелла до одного. Башизмы можно использовать только в bash и даже не все и не во всех версиях баш. > Почему это _НАСТОЛЬКО_ПЛОХО_, чтобы не пропускать довольно необходимое > изменение в сборочницу? Понятие "довольно необходимые" очень относительно. Любое изменение довольно необходимо. Повторю, я совершенно не против предложенного функционала, но я против того как это реализовано. Утрируя я могу сказать, что я также против довольно необходимых изменений c использованием python или ruby в этом проекте. Это моя позиция. Она может отличаться от позиции Димы. P.S. Это оффтопик для этой баги. Если вы хотите это обсудить, то пишите мне лично или в рассылку. 174642 20 rider 2018-10-02 07:37:07 +0300 Да согласен с Лёшей - использование расширений bash в именно этом проекте недопустимо. gear может работать без hasher и не на альте. Лучше эту фичу сохранить. Правда, ему для полного счастья ещё требуется rpm от альта, но это уже немного другой разговор. 182555 21 ldv 2019-06-19 01:42:26 +0300 *** Bug 35219 has been marked as a duplicate of this bug. *** 187777 22 rider 2020-02-12 13:41:53 +0300 Если Ваня этим не занимается, то давайте попросим автора gear добавить эту фичу. 187779 23 slev 2020-02-12 13:49:41 +0300 Очень интересная фича. Можно узнать про ее статус? 187780 24 imz 2020-02-12 14:06:17 +0300 (In reply to Stanislav Levin from comment #23) > Очень интересная фича. > Можно узнать про ее статус? У меня в целом всё готово было (аз я уже просил approve), только legion@ не хотел видеть там в коде один bashism, а также тестов стало больше и их задание, к сожалению, менее вразумительно стало выглядеть. (По-моему, замечание от ldv@ было.) 195165 25 ldv 2020-12-27 14:39:58 +0300 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). 195170 26 rider 2020-12-27 19:42:58 +0300 Спасибо, а это будет работать для всех stable веток ? 195171 27 ldv 2020-12-27 19:53:46 +0300 (In reply to Anton Farygin from comment #26) > Спасибо, а это будет работать для всех stable веток ? Тестирование на сборочнице пока проходит успешно. 196966 28 rider 2021-03-15 12:30:22 +0300 Спасибо. Начал пользоваться и наткнулся на то, что у меня есть один случай, когда эта опция была бы полезна для директивы tar Насколько сложно будет её добавить ? Стоит ли по этому поводу заводить отдельный FR ? 196970 29 ldv 2021-03-15 15:02:43 +0300 (In reply to Anton Farygin from comment #28) > Спасибо. Начал пользоваться и наткнулся на то, что у меня есть один случай, > когда эта опция была бы полезна для директивы tar > > Насколько сложно будет её добавить ? Стоит ли по этому поводу заводить > отдельный FR ? Концептуально exclude для архивов (tar, zip) ничему не противоречит, сложность реализации аналогична exclude для dif, на самом деле даже проще, потому что можно использовать реализацию exclude для diff в качестве примера. Для отслеживания лучше завести отдельный FR. 196972 30 legion 2021-03-15 15:28:23 +0300 (Ответ для Anton Farygin на комментарий #28) > Спасибо. Начал пользоваться и наткнулся на то, что у меня есть один случай, > когда эта опция была бы полезна для директивы tar > > Насколько сложно будет её добавить ? Стоит ли по этому поводу заводить > отдельный FR ? Не сложно. Лучше открой новый баг и повесь на меня.