Bug 26184
| Summary: | format of epoch-ed provides differ on i586 and x86_64 | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | viy <viy> |
| Component: | rpm-build | Assignee: | Gleb F-Malinovskiy <glebfm> |
| Status: | NEW --- | QA Contact: | qa-sisyphus |
| Severity: | normal | ||
| Priority: | P3 | CC: | arseny, glebfm, imz, n3npq |
| Version: | unstable | ||
| Hardware: | all | ||
| OS: | Linux | ||
I suspect that it might be due to optimization of provides по времени тоже похоже на появление оптимизации provides. можно оптимизацию поравить (для совместимости со старшими rpm) можно тест подправить. чтобы фильтровал s,-0:,-, из Provides tracked at https://bugs.launchpad.net/rpm/+bug/911016 актуально, вылезло вот только в [#73551] FAILED srpm=antlr-2.7.7-alt9_13jpp6.src.rpm http://git.altlinux.org/tasks/73551/logs/events.1.1.log 2012-Jun-13 18:35:08 :: task #73551 for sisyphus started by viy: #100 build antlr-2.7.7-alt9_13jpp6.src.rpm 2012-Jun-13 18:35:09 :: cloned Sisyphus 2012-Jun-13 18:35:11 :: [i586] #100 antlr-2.7.7-alt9_13jpp6.src.rpm: build start 2012-Jun-13 18:35:11 :: [x86_64] #100 antlr-2.7.7-alt9_13jpp6.src.rpm: build start 2012-Jun-13 18:40:49 :: [x86_64] #100 antlr-2.7.7-alt9_13jpp6.src.rpm: build OK 2012-Jun-13 18:41:05 :: [i586] #100 antlr-2.7.7-alt9_13jpp6.src.rpm: build OK 2012-Jun-13 18:41:13 :: build check OK --- antlr-tool-2.7.7-alt9_13jpp6.noarch.rpm.i586 2012-06-13 18:41:14.031424758 +0400 +++ antlr-tool-2.7.7-alt9_13jpp6.noarch.rpm.x86_64 2012-06-13 18:41:14.099424324 +0400 @@ -16,3 +16,3 @@ Requires: rpmlib(PayloadIsLzma) -Provides: antlr = 0:2.7.7-alt9_13jpp6 +Provides: antlr = 2.7.7-alt9_13jpp6 Provides: /usr/bin/antlr = 10 error (#100): non-identical noarch packages 2012-Jun-13 18:41:15 :: noarch check FAILED 2012-Jun-13 18:41:15 :: task #73551 for sisyphus FAILED %package tool Group: Development/Java Summary: ANother Tool for Language Recognition (java version) Requires(post): alternatives Requires(preun): alternatives BuildArch: noarch Provides: %name = %version-%release Provides: %name = %epoch:%version-%release Obsoletes: %name < %version-%release Conflicts: %name < %version-%release wontfix? Я то потом убрал %epoch: из provides, здесь это можно было. Но если бы нашлась софтина, которая хотела бы provides с %epoch, то был бы тупик. убрал %epoch: из provides - unmet не убрал %epoch: из provides - не прошел проверку :( Правильнее все-таки пофиксить проверку или apt или rpm или что что проблему порождает. Ведь уже не раз вылезает эта грабля. (In reply to comment #6) > Provides: %name = %version-%release > Provides: %name = %epoch:%version-%release Здесь 2 provides одного имени с разными EVR. > Obsoletes: %name < %version-%release > Conflicts: %name < %version-%release Здесь какой-то совершенно неуместный Conflicts. (In reply to comment #7) > Я то потом убрал %epoch: из provides, здесь это можно было. Зачем два разных provides для одного имени? Как может работать механизм сравнения версий в случае, когда один provides удовлетворяет, а другой provides с тем же именем не удовлетворяет? Я полагаю, что это undefined behaviour. > Правильнее все-таки пофиксить проверку или apt или rpm или что что проблему > порождает. > > Ведь уже не раз вылезает эта грабля. Я не утверждаю, что rpmbuild всегда ведет себя правильно, но эти грабли вылезают в каких-то странных машиносгенеренных спеках. Мне кажется, что у нас есть более актуальные задачи, чем повышение качества обработки неправильных спеков. конечно, это не тот баг, который нужно срочно фиксить, это симптом какого-то сбоя, возможно в apt. Вдруг когда-то найдется возможность его починить. Т.е. и баг есть, но есть и возможность его обойти. Не проблема, если он и год будет висеть. Это не горит. А вот что для меня горит, это https://bugzilla.altlinux.org/show_bug.cgi?id=27419 [add src.list from autoimports.altlinux.org to the lists checked] на этот я бы просил обратить внимание. |
Description
viy 2011-08-29 01:05:46 MSK