[Bug 188974] Review Request: libGLw

bugzilla at redhat.com bugzilla at redhat.com
Mon Aug 7 21:07:15 UTC 2006


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 at mharris.ca  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.




More information about the package-review mailing list