[devel] %update_desktopdb vs %update_menus [JT]

[Damir Shayhutdinov]

>  > Если же автор-инициатор NMU не хочет продумывать способы интеграции
>  > своего NMU в историю развития пакета и вместо этого хочет гонять
>  > робота после каждой сборки

> Дамир!
>  Вы же программист - вам должно быть это понятно.
>  Вопрос не в том, делать или не делать способы интеграции с .git,
>  а в том, сколько времени это займет.
Интеграция с git тут конечно была бы полезна. Но на самом деле вовсе
не нужно делать эту интеграцию в полном виде. По идее достаточно было
бы рассылки на личную почту патчей, которые бы потом можно было
применить командой git-am или git-apply.

>  Например, на repocop, как и предсказывает теория, ушло времени
>  ровно в три раза больше, чем то время, которого, по моей субьективной
>  оценке, хватило бы, если я писал бы repocop "для себя".
>
>  Но я это учитывал, и решил, что в силах потратить времени x3.
>  репокоп есть.
По самому инструменту претензий нет - получился он хорошим, большое спасибо!

>  Теперь робот для MNU. Это часть сложного хозяйства, писавшегося
>  долгое время, без документации, с непроработанными интерфейсами.

Проблема не в этом. Просто ранее на результаты NMU, выполненными
роботами (всякие QA-роботы, пересобирающие пакеты при смене soname
библиотеки), можно было махнуть рукой - все равно следующая пересборка
мантейнером не может "чего-то не учесть" - ведь пересборка в новом
окружении (без изменения) и была смыслом NMU.

Теперь же ты вступаешь на неисследованную территорию, когда надо
обеспечить не только пересборку пакета, но и сохранение изменений,
внесенных роботом, в последующих сборках пакета мантейнером. Если по
"человеческим" NMU с автором NMU можно как-то договориться о формате
интеграции (патч там по почте, коммит в гите или просто передать пакет
тому кто сделал NMU), то с роботом ничего не получится. Все эти
переговоры должен вести не робот, а автор робота.

При этом просто еще одно робото-NMU после пересборки мантейнером
проблему не решает, а пользователям Сизифа придется качать удвоенный
объем данных. Я считаю такое "автоNMU" неприемлемым. NMU - это
исключение, которое никогда не должно быть правилом.

>  Прежде чем писать интеграцию с .git, это все хозяйство нужно
>  привести в порядок. Продумать интерфейс, написать толковую
>  документацию. Это еще займет x2 времени от его разработки.
Да не в git'e дело.

>  Что называть конкретные даты я морально не готов.
>  Лето, осень, зима, следующий год?
>
>  А все это время пакеты так и будут лежать,
>  а по ним будут small bugs ползать...

Конкретно в этом случае (update_desktopdb) можно было бы устроить NMU,
которое было бы удобно всем.

А именно:
1) внести функциональность update_desktopdb в update_menus.
2) NMU/повесить баги на пакеты, в которых нету ни update_menus ни
update_desktopdb, но есть .desktop.
3) NMU (простая пересборка) на пакеты, которые содержат update_menus
но не содержат update_desktopdb.
4) Отметить макрос update_desktopdb как устаревший (obsolete).

Тогда договариваться об интеграции придется только с мантейнерами
пакетов, затронутых пунктом 2. Результаты NMU пакетов из пункта 3
можно смело выкинуть - они не важны.

А тест для пункта 2) - когда есть .desktop, лежит там где надо, но
нету update_menus/clean_menus - вообще можно по идее в какой-нибудь
sisyphus_check положить (или даже в rpm). Тогда мантейнер не сможет
залить неправильный пакет в репозитарий (и не сможет потерять
результаты NMU).

>  Моя позиция - меньше обещать, больше делать.
>  Что плохого в этой позиции?
Плохо тут то, что с роботом не договоришься, а пока результатом его
работы не очень удобно пользоваться. Поэтому приходится договариваться
с автором робота :)

Если хотите - я могу развернуто объяснить, почему сейчас результатом
работы робота могут воспользоваться только роботы, и что нужно
сделать, чтобы минимизировать шансы потери NMU.

>  P.S. С удовольствием приму помощь в разработке.
Я могу помочь, но для начала надо все-таки понять, в каком направлении
движется разработка.