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@xxxxxxxxxx 2006-08-07 16:57 EST ------- (In reply to comment #13) > Looks pretty good so far... offhand, > > 1. 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. > 2. 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. > 3. -devel should > Requires: libGL-devel > since its headers include references to GL/gl.h GL/glx.h Right > 4. (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. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review