Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libGLw
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188974
------- Additional Comments From mharris@mharris.ca 2006-08-07 16:57 EST ------- (In reply to comment #13)
Looks pretty good so far... offhand,
- IMO, package should follow upstream name and version, ie,
Name: mesa-libGLw Version: 6.5 that is, unless there is (strong, but so far unclear to me?) reasoning to do otherwise. If renamed, then you no longer need the Obsoletes: mesa-libGLw
In theory, this is a good idea, as it would allow for someone to package SGI libGLw, or some other implementation that could theoretically exist, which was the intent behind existing package naming and virtual provides. I agree that the package version should probably match the Mesa version it is from also. If it is named "mesa-libGLw{,-devel}", then the Obsoletes indeed is not needed.
- These Obsoletes seem overkill to me:
Obsoletes: Mesa Obsoletes: XFree86-libs Obsoletes: xorg-x11-libs These are (should be!) already Obsoleted elsewhere. IMO, no need to include them here.
libGLw was present in the above packages in older OS releases previously, and as such, those Obsoletes lines must remain in order for package upgrading to work properly. They should IMHO not be removed ever.
- -devel should
Requires: libGL-devel since its headers include references to GL/gl.h GL/glx.h
Right
- (minor/cosmetic) in -devel, change
Requires: libGLw = %{version}-%{release} to Requires: %{name} = %{version}-%{release} to save hassle if/when pkg is ever renamed.
Agreed, that makes sense.
(In reply to comment #14)
And 5. (corrolary to 2,3), since this is a pkg split, you may want to consider including in main pkg: Requires: mesa-libGL >= VER-REL and in -devel pkg
This is bad for 2 reasons:
1) It forces libGLw to have a dependency on the mesa implementation of libGL, instead of working with _any_ libGL implementation. Whenever possible, dependencies on libGL should be generic, not implementation specific.
2) rpm automatically detects a dependency on libGL during packaging and will add a Requires: libGL.so.1 to the package, so there is no need to hard code one in the spec file. The same applies to all library packages.
Requires: mesa-libGL-devel >= VER-REL where VER-REL represent when the split occurred.
Also a bad idea. It should only contain:
BuildRequires: libGL
and in the libGLw-devel it should have: Requires: libGL-devel
No version should be specified on either, as these virtual provides are intentionally versionless and implementation agnostic.
This could also be accomplished with using Conflicts: mesa-libGL < VER-REL but that's potentially messier. I'll leave it up to as to how you'd rather deal with this (if at all).
In general "Conflicts" should always be avoided, and Obsoletes used instead, for the benefit of anaconda and yum. Obsoletes usually does the right thing without user intervention for upgrade handling case. If someone has an older version of mesa-libGLw or -devel installed, so long as all of the above Obsoletes lines I indicated should NOT be removed are present, and so long as Obsoletes: mesa-libGLw{,devel} is present (if the package remains named libGLw{,-devel}), then upgrades should always work properly without any conflicts at all.
If the Obsoletes were inadvertently or intentionally missing however, rpm itself would see the file conflicts during install time and inform the user, so a hard coded Conflicts line is redundant.
I'd avoid using Conflicts unless there is an actual problem it is solving which rpm does not automatically detect on it's own, or which proper Obsoletes lines do not fix.
Hope this helps.