15467 2008-04-25 20:58:23 +0400 binary <-> source package bug navigation 2021-07-01 13:32:51 +0300 1 1 2 Infrastructure Infrastructure bugzilla.altlinux.org unspecified all Linux CLOSED WONTFIX P2 enhancement --- 16711 18644 1 dottedmag mcpain nbr rider vitaly.fedrushkov dottedmag oldest_to_newest 68988 0 dottedmag 2008-04-25 20:58:23 +0400 Для увеличения юзабельности компонента загоняния багов, стоит предусмотреть возможность резолвинга binary пакетов в соответствующие source-пакеты. 68989 1 dottedmag 2008-04-25 21:07:13 +0400 Что-то я прогнал. В багзилле и так бинарные пакеты. 69053 2 vvk 2008-04-28 11:53:04 +0400 Э, а я подумал что ты хочешь чтобы бинарных компонентов не было, а только source, т.е. чтобы баги на binary-компоненты вешались не на них а на тот source-компонент, из которого собирается binary. 69056 3 dottedmag 2008-04-28 12:14:52 +0400 Нет, не хочу. А надо? В debian, в принципе, можно видеть баги как на бинарные пакеты, так и на source, из которых они собираются. 69057 4 vvk 2008-04-28 12:39:03 +0400 Да вроде не надо. Разве что было бы полезно иметь возможность легко найти все баги на подпакетах source-пакета xxx. substring/regexp в поиске тут не совсем канает, т.к. названия подпакетов вовсе не обязательно содержат в себе xxx. 69058 5 dottedmag 2008-04-28 12:43:15 +0400 Ок. 82562 6 dottedmag 2008-12-10 17:08:22 +0300 В 3.2 82616 7 vitaly.fedrushkov 2008-12-11 06:48:32 +0300 Все зависит от того, на что реально назначаются ответственные: на source или на binary. Этот объект и должен стать компонентом, а на оставшийся создать custom field. Если есть таблица перехода, одно поле вычислять из другого на лету. Это даст возможность вести поиск, отчетность и т.п. в разрезе того и другого. 82618 8 dottedmag 2008-12-11 08:11:04 +0300 И правда: компонентом должен быть source package, custom field - binary package. При создании багов нужен будет кастомный интерфейс для выбора компонента, но это не смертельно. 82621 9 vitaly.fedrushkov 2008-12-11 09:20:14 +0300 Проблема будет если отношение между ними не один-ко-многим. Если список известен статически, его можно даже не тащить в Bugzilla. Надо лишь заполнить список выбора для _текстового_ поля custom field. См. идею тут: https://doctor.mozilla.org/?action=edit&file=bugzilla-org/src/installation-list/index.html 82623 10 dottedmag 2008-12-11 09:58:17 +0300 Внутри одного продукта отношение всегда один-к-многим. Спасибо за ссылочку, подумаю. А custom field ведь глобален, а не per-product? Придётся тогда вешать тэги "этот продукт - про репозиторий / это продукт - не про репозиторий", и менять GUI. Впрочем, для репозиториев и так GUI слегка адаптировать не помешает. 82624 11 dottedmag 2008-12-11 10:00:35 +0300 Впрочем, понял, зачем нужен список в Bugzilla: чтобы можно было этот custom field нормально редактировать: в виде combobox при перевешивании на другой binary package внутри одного source package, и для autocompletion при перевешивании на другой source package. Тут ещё много разного геморроя может открыться: скажем, при перемещении багов между продуктами, и при работе с пакетами, у которых ровно один бинарный пакет собирается из source - в этом случае жестоко заставлять выбирать пользователя ещё и бинарный. 88650 12 dottedmag 2009-04-04 02:03:00 +0400 *** Bug 15923 has been marked as a duplicate of this bug. *** 199823 13 mcpain 2021-07-01 12:18:51 +0300 А с этим что? 199828 14 rider 2021-07-01 13:32:51 +0300 я думаю, что в этом смысле лучше ничего не менять. Примерно это же показывает обсуждение от 2008 года.