Sorry for the delay in getting back to you DRC... Stuff at $dayjob is
keeping me too busy.
If you would like to examine the spec file as it exists now in the koji
build system or the package copies are at:
http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora17/spec/8/VirtualGL.spec
and
http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora17/SRPMS/VirtualGL-2.3.1-8.fc17.src.rpm
<http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora17/SRPMS/VirtualGL-2.3.1-6.fc17.src.rpm>
Feel free to download it, examine it and rebuild it. I did not create it
from scratch like I did the bumblebee rpm but I had to make a bunch of
changes to the one they gave me before it passed for the fedora QA
guidelines.
On Tue, Aug 28, 2012 at 9:10 PM, DRC <dcomman...@users.sourceforge.net>wrote:
>
> -- VirtualGL's faker libraries aren't versioned and never will be. A
> lot of Linux distro maintainers knee jerk at that without stopping to
> think for a moment what versioning is supposed to do and why it makes no
> sense for an interposer library.
>
Yup, as noted, all set.
>
> -- Probably the best solution to your problem regarding installing the
> fakers in a non-system directory (I would suggest /usr/lib[64]/VirtualGL
> and also would suggest putting the libGL.so symlink in that same
> directory, for simplicity) would be for me to modify the build system
> such that vglrun is dynamically generated with the appropriate prefix.
>
Which is what we did. A new vglrun would be great if it doesn't break
other distros or users, etc. We use the %{_libdir} macro which will put the
faker libraries in either /usr/lib64/VirtualGL/ or /usr/lib/VirtualGL/
depanding on which platform the rpm package is built for. (Fedora is really
big on these macros in the spec file because it makes things easier as the
distro gets upgraded, changes are made, etc.) The vglrun is currently being
patched for this by patch0. (.redhatpathsfix)
> -- I would like to somehow maintain the ability to install our official
> version of VirtualGL on these platforms without causing problems. I
> think we should open a dialog regarding that, such as what happens when
> a user has our version installed and they do a 'yum update'. Maybe the
> official binaries need to change names, maybe we need to consider
> installing all of our stuff under /opt/VirtualGL and using alternatives
> to maintain the /usr/bin symlinks, or maybe we just adopt the same
> packaging standards as Fedora and assume that one package replaces the
> other. Suggestions welcome.
>
I'm sorry I don't have a good answer here. I had thought about perhaps the
official rpms having a high epoc number, but I guess that won't work.
My sponsor said: "There really aren't any great ways of dealing with this.
Probably the best way would be for the virtualgl project to provide its
own yum repo then people can use yum-priorities to prefer that repo over
the fedora repos.
My hope would be that virtualgl would come to see the Fedora version as
equal to their own and point people to installing the Fedora version."
I have set up a yum repo before and its not too hard. Basically you have a
web directory (can also use ftp) and you drop rpms in there and run the
createrepo command with the path to the repo as an argument. One thing that
complicates it is that the rpms need to be signed. (rpm --addsign
/path/to/rpmfile) I could perhaps help with that offlist if you need it?
Then when you put a new version of VirtualGL in your repo all the people
with the official version could get updates when yum update runs.
> -- common/glx.h and common/glxext.h are not bundled libraries. They're
> simply headers, included because not all of the platforms VirtualGL
> builds on have a recent enough set of OpenGL headers, and it's just
> easier to build against our own. I don't see why they would cause
> problems.
>
>
Yeah, We need to build against our system headers according to my project
sponsor. But we are not *at all* trying to tell you that you need to stop
doing that or anything or that it is wrong. Its juts a rule we have in the
fedora project. If other distros need it please don't mess them over
because of us. :)
> -- I am willing to add a VGL_SYSTEMFLTK option to the build so that it
> looks for FLTK elsewhere, rather than building the in-tree version.
>
>
Fedora project is suggesting "VGL_USE_SYSTEM_FLTK", more in line with
similar variables from vtk/paraview cmake projects.
Please understand I am EXTREMELY new at this. In fact this is my first
package ever in the fedora project. So I did not mean to cause problems. I
wanted to see VirtualGL have a wider audience since it will
be installable from the many many packages in the fedora distro without
having to fuss with anything first. Plus my own package needs this as a rpm
dependency so I'm going to have to get this one in if I am to have any hope
for getting bumblebee into fedora.
I did not push out the VirtualGL packages into an update in Bodhi at this
time. So people can't install it yet if you were worried about that.
Thanks,
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
VirtualGL-Devel mailing list
VirtualGL-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
