Сейчас ошибку можно повесить только на бинарный пакет (по имени). Но нет, например, возможности повесить ошибку на исходный пакет. А это нужно в некоторых случаях, когда или невозможно определить имя бинарного пакета, или бинарные пакеты содержат в своём имени версию. Предлагаю добавить исходные пакеты в списки компонент.
Сейчас в Sisyphus 1031 пакет, в котором из исходного пакета не собирается ни один одноимённый бинарный.
$ comm -23 <(cut -f1 Sisyphus/files/list/src.list |sort -u) <(cut -f1 Sisyphus/files/list/bin.list |sort -u) |wc -l 1025 1025 != 1031, но близко.
Я нашёл ошибку у себя в базе, но и у тебя в join не всё гладко: Посмотри, например, пакеты (исходные) libctl5 и libctl. я джойнюсь не по имени пакета, а по хешу его содержимого.
(In reply to Anton Farygin from comment #3) > Я нашёл ошибку у себя в базе, но и у тебя в join не всё гладко: > Посмотри, например, пакеты (исходные) libctl5 и libctl. Из пакета libctl собирается не libctl, а libctl7, в то время как из пакета libctl5 собирается libctl? В таком случае будет довольно сложно повесить баг на исходный пакет libctl. Вообще не надо разводить такую путаницу. Возможно, стоит запретить собирать бинарный пакет с именем, совпадающим с именем другого исходного пакета, и наоборот, собирать исходный пакет с именем, совпадающим с именем бинарного пакета, собранного из другого исходного.
да, я тоже так подумал - попытка собрать из одного исходного пакета бинарный пакет с именем другого исходного пакета должна считаться за баг. Как и попытка отправить в репозиторий исхоный пакет с именем, которое уже занято другим бинарным пакетом.
(Ответ для Anton Farygin на комментарий #5) > да, я тоже так подумал - попытка собрать из одного исходного пакета бинарный > пакет с именем другого исходного пакета должна считаться за баг. > > Как и попытка отправить в репозиторий исхоный пакет с именем, которое уже > занято другим бинарным пакетом. А что делать пока в репозитории есть такие пакеты? У компонента нет явных зависимостей на архитектуру или на что-нибудь ещё такое, что позволило бы отличить src от bin
Например, я смог на стенде перевесить багу хромиума на ppc и arm, хотя для таких архитектур хромиум не поддерживается.
А в bugzilla можно делать покомпонентные архитектуры ? если да, то тогда всё выглядит просто - надо добавить архитектуру source и для каждого пакета (бинарного и исходного) загружать информацию о поддерживаемых архитектурах.
(Ответ для Anton Farygin на комментарий #8) > А в bugzilla можно делать покомпонентные архитектуры ? > если да, то тогда всё выглядит просто - надо добавить архитектуру source и > для каждого пакета (бинарного и исходного) загружать информацию о > поддерживаемых архитектурах. Средствами багзиллы - нельзя. Пока нет других вариантов, кроме как в кратчайшие сроки устранить существующие конфликты между src и bin, либо придумать правило, которое не даст их спутать и реализовать проверку, чтобы это правило не нарушалось. Кроме того, есть 62 компонента: krb5 libirrlicht telepathy-mission-control grub libdvdread antlr libnetcdf libzeitgeist portsentry SimGear libgtkhtml qt5-phonon installer libwebp libgphoto2 libosip2 libexo falkon asio timetool libaom libsrtp coin3d telepathy-glib maven2 perl clanlib libqhttpengine dhcp Mesa libqtkeychain boost libgeotiff beecrypt libtorrent libqtkeychain-qt5 libtiff pari openldap libevent doublecmd tbb libgcrypt libspice-gtk libmtp libyaml esound mono penguin-command gimp-help libarchive openmotif pam_mktemp gnome-menus libfm nfs hiredis msv SDL ipython libass maxima Бинарные пакеты с этими именами уже не существуют, но существуют src.rpm с такими именами и непонятно, что делать с такими компонентами. На них были заведены баги, поэтому компоненты не удалялись.
(Ответ для Олег Соловьев на комментарий #9) > (Ответ для Anton Farygin на комментарий #8) > > А в bugzilla можно делать покомпонентные архитектуры ? > > если да, то тогда всё выглядит просто - надо добавить архитектуру source и > > для каждого пакета (бинарного и исходного) загружать информацию о > > поддерживаемых архитектурах. > > Средствами багзиллы - нельзя. понятно. > Пока нет других вариантов, кроме как в кратчайшие сроки устранить > существующие конфликты между src и bin, либо придумать правило, которое не > даст их спутать и реализовать проверку, чтобы это правило не нарушалось. Я не вижу тут никаких проблем, т.к. таких пакетов крайне мало и уже после регистрации ошибки ментейнер решит, его это ошибка или нет. > > Кроме того, есть 62 компонента: <skip> > > Бинарные пакеты с этими именами уже не существуют, но существуют src.rpm с > такими именами и непонятно, что делать с такими компонентами. > > На них были заведены баги, поэтому компоненты не удалялись. А это даже хорошо и после загрузки src пакетов в компоненты встанет на свои места.
(Ответ для Dmitry V. Levin на комментарий #4) > Возможно, стоит запретить собирать бинарный пакет с именем, совпадающим с > именем другого исходного пакета > собирать исходный пакет с именем, совпадающим с именем бинарного пакета, > собранного из другого исходного. Таких пакетов как минимум 4: srpm libctl5 ---> bin libctl srpm clip ---> bin libclip srpm mate-file-manager ---> bin mate-file-manager-extensions srpm vtk ---> bin vtk-data
Запушено http://git.altlinux.org/people/mcpain/packages/?p=bugzilla-repo-sync.git;a=commit;h=d25d998e68d145bbf08c9f9d170f2f46b6b0e93f
Есть возражения против применения изменений ?
(Ответ для Anton Farygin на комментарий #13) > Есть возражения против применения изменений ? Пока что у меня есть, нашел багу.
(Ответ для Олег Соловьев на комментарий #14) > (Ответ для Anton Farygin на комментарий #13) > > Есть возражения против применения изменений ? > > Пока что у меня есть, нашел багу. Починено, сейчас актуален коммит 39f8a6d
