Bug 175500
| Summary: | Review Request: compat-wxGTK & compat-wxPythonGTK2 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tom "spot" Callaway <tcallawa> | ||||||
| Component: | Package Review | Assignee: | Matthias Saou <matthias> | ||||||
| Status: | CLOSED RAWHIDE | QA Contact: | David Lawrence <dkl> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | rawhide | CC: | alex, fedora-package-review, joel.schaerer, mattdm, matthias, pertusus | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2006-04-19 21:40:48 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 154618, 163779 | ||||||||
| Attachments: |
|
||||||||
|
Description
Tom "spot" Callaway
2005-12-11 23:47:46 UTC
These look pretty good (apart from the added tabs, when the spec files used spaces ;-)). Have you tried to modify and build some applications using them? (just to know if it'll be easy or not), like audacity for instance? If no one else steps up, I wouldn't mind reviewing the packages, but I'll need to do some further testing. Matthias -- by all means, please review. :) Packages that will need to have their spec file updated for the change :
- audacity
- bochs
- comical
- pgadmin3
- scorched3d
I've only tested a rebuild of audacity, and it worked fine changing just :
- The BuildRequires to add "compat-"
- The %build section to add just before the %configure line :
export WX_CONFIG="%{_bindir}/wx-2.4-config"
Please consider applying the spec file patch I'll attach as it fixes many
minor cosmetic issues in the spec file. It also changes to 755 the mode of
the %ghost'ed script, so that rpmlint stops complaining.
Created attachment 122410 [details]
Spec file patch
Created attachment 122411 [details]
Spec file patch
Since the patches only contain minor changes, I already approve both packages. I see these have been imported, but only compat-wxGTK bas been built in FC5, is that wanted? What about FC4? There's a conflict in the virtual Provides of the published packages! Currently both wxGTK-devel and compat-wxGTK2-devel as well as wxGTK and compat-wxGTK2 contain "Provides: wxGTK2-devel = some version" and "Provides: wxGTK2 = some version" This makes them competing packages. You cannot do this, as wxGTK and compat-wxGTK2 are _not_ equivalent. It causes RPM to let the newer version win, which results in removal of the packages with the older versions during installation or in a failed transaction check. compat-wxGTK2-devel is broken! $ wxgtk2-2.4-config --cflags -I/usr/lib/wx/include/gtk2-2.4 -DGTK_NO_CHECK_CASTS -D__WXGTK__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES It points to /usr/lib/wx/include/gtk2-2.4 but the compat-wxGTK2-devel package contains headers in a different path: /usr/lib/wx/include/gtk-2.4/wx/setup.h On the contrary, compat-wxGTK-devel is okay. Michael -- what's your advice for resolving comment #8? I'd not like to remove that from the main wxGTK package, but it seems necessary here.... Re: comment 9 --- compat-wxGTK.spec.~1.2.~ 2006-01-06 18:52:38.000000000 +0100 +++ compat-wxGTK.spec 2006-03-17 21:51:27.000000000 +0100 @@ -288,7 +288,7 @@ %ghost %{_bindir}/wx-2.4-config %{_bindir}/wxgtk2-*-config %{_libdir}/libwx_gtk2[-_]*.so -%{_libdir}/wx/include/gtk-2* +%{_libdir}/wx/include/gtk2-2* %files common -f wxstd.lang %defattr(-,root,root,-) Re: comment 10 Remove the Provides from the compat-wxGTK2{-devel} packages, but not from the new wxGTK{-devel} packages. Btw, compat-wxGTK{-devel} must not "Provides: wxGTK = ..." and
"Provides: wxGTK-devel = ..." either.
And then any packages which link against this must work just by virtue of the automatic library deps, and any which have explict requires statements must be fixed, yeah? > And then any packages which link against this must work just > by virtue of the automatic library deps That's how ordinary "compat-" packages work anyway. You let a _new_ compat- package provide the SONAMES needed by old binaries. The SONAME dependencies don't care which package contains the needed files. > and any which have explict requires statements must be > fixed, yeah? Those packages are broken by design. Same applies to BuildRequires and the current brokeness due to these "virtual provides" madness. A package which "BuildRequires: wxGTK2-devel" cannot be built with compat-wxGTK2-devel which "Provides: wxGTK2-devel" and vice versa. Make sense. And is ideal, because it's someone else's problem. *grin* Looks like compat-wxPythonGTK2 hasn't yet been built on devel or FC-5. Causes some problems like bug #188215. The specific code in bug #188215 (simply importing wxPython) should work fine with the new 2.6.x wxPython. When will the new packages be available? The code i would like to use is mainly incompatible with wx2.6, so the packages are going to be needed! As of today, i only see the old package: wxPythonGTK2.i386 2.4.2.4-7 extras in extras, and it doesn't work (cf bug #188215) New packages should now be available. Shouldn't package reviews be closed as NEXTRELEASE? Ehh. Semantics. I think of NEXTRELEASE as "FC-6" as opposed to "Immediately in repo", but I could see either being valid. They're built. That's what really matters, right? :) (In reply to comment #21) > Ehh. Semantics. > > I think of NEXTRELEASE as "FC-6" as opposed to "Immediately in repo", but I > could see either being valid. Sure, just wondering whether the process had changed. I was going off of step 14 of: http://fedoraproject.org/wiki/Extras/NewPackageProcess > They're built. That's what really matters, right? :) Indeed, thank you. |