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-07-27 02:44 EST ------- (In reply to comment #1) > Some quick comments after looking at the spec: > > * It would be better to have your real name on the bug report. > Not a big deal, it is in the spec anyway. Irrelevant. > * the Buildroot is no the right one > http://fedoraproject.org/wiki/Packaging/Guidelines#head-f196e7b2477c2f5dd97ef64e8eacddfb517f1aa1 It'd be nice if emacs et al defaulted to the official BuildRoot tag. > * no need to conditionalize openmotif support, it should always > be true in fedora extras There's no need to conditionalize the support for many of the things which Fedora Core and Fedora Extras packages already conditionalize. Conditionalizing features is itself a feature, which can be useful to rebuilders, and for a variety of other reasons. This is not a flaw in the package, and is IMHO orthagonal to inclusion of the package into Extras. > * the non free file shouldn't be distributed. I generally completely agree with that. In this case the file is not open-source, but it both unused, and is legally redistributable, so it is not a problem legally or practically for it to be in the package, however it would be nice if upstream removed it in the future. There's no real-world gain of removing it IMHO, and it has the cost of having to re-do that every time there is a new upstream release of Mesa which contains it. Also, our tarballs no longer match upstream's then, so can't be verified by MD5sum or whatever. > what I do in such > cases is provide with a script in SourceXX that unpack the upstream > tarball, remove the offending files and repack, such that a reviewer > can easily reproduce what you did in the SOURCES directory. An example > where I do that is grads (with the script grads-remove-files and the > list of files grads-removed-files-list) although you could do more simply > since you only have one file to remove. Sounds reasonable for files which are not legally redistributable, such as mp3 decoder software, and other things which are legally encumbered. In the case of this file, it is redistributable as-is, and is unused, so moot. (In reply to comment #2) > Another remark, maybe > BuildRequires: mesa-libGL-devel > should be > BuildRequires: libGL-devel > but I haven't really investigated if there is a need for the mesa > implementation or not. Yup, "BuildRequires: libGL-devel" should be used by anything needing libGL, unless a specific implementation of OpenGL is required. (In reply to comment #3) > 2 more comments: > > * You should add to %docs Mesa-6.5/src/glw/README > as it contains the licence. Sounds reasonable. > * I am not convinced that it is right to make a source package out of a > whole package by taking only bits of what is in the tarball while the > remaining is in another source package. May be worth asking on the extras > list. Couldn't the upstream project be convinced to split the tarball? Adam more or less _is_ the upstream person who is splitting the tarball essentially.(In reply to comment #4) > (In reply to comment #1) > > * the non free file shouldn't be distributed. what I do in such > > cases is provide with a script in SourceXX that unpack the upstream > > tarball, remove the offending files and repack, such that a reviewer > > can easily reproduce what you did in the SOURCES directory. An example > > where I do that is grads (with the script grads-remove-files and the > > list of files grads-removed-files-list) although you could do more simply > > since you only have one file to remove. > > That feels like such overkill. I'll give it a shot though. Definite overkill, with no real-world gain, and no real-world risk of not doing it. > > * I am not convinced that it is right to make a source package out of a > > whole package by taking only bits of what is in the tarball while the > > remaining is in another source package. May be worth asking on the extras > > list. Couldn't the upstream project be convinced to split the tarball? > > No, they can't. This battle has been fought and lost before. We already slice > up the default build of Mesa, since we don't use its libglut for being non-free. Wrong. Brian Paul split Mesa's GLUT library out into MesaGLUT in the 6.4 release. Fedora doesn't remove the files, we just don't ship the MesaGLUT tarball. The Mesa source just seems to have some leftover glut related files still stuck in it. No idea if they're just files that were missed, or if they're needed for anything, but we don't ship them in the binary packages, so it doesn't much matter. > Other changes applied, along with some fixed %package statements to make the > binary rpm not be named libGLw-libGLw-*. New versions uploaded to the same URLs > as before. libGLw-libGLw-libGLw would be a cool package name. ;) (In reply to comment #6) > 2 remarks: > - The summary isn't quite correct: LibGLw provides Xt and Xm OpenGL widgets. > It doesn't provide Xaw widgets. > > - Instead of building a standalone libGLw from Mesa's tarball, wouldn't it be > easier to use SGI's original sources (I don't know if and where they still are > available as a separate tarball) and to patch them to Mesa's state, or even to > drop Mesa's libGLw in favor of SGI's? More importantly here I think, is which upstream do you think is more likely to fix bugs in libGLw and/or respond to developer inquiries and bug reports, etc? I would wager the Mesa project would be much more responsive than would SGI, and definitely Mesa project is more likely to provide bugfixed tarballs in an open-project style manner. -- 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