Better you than me. :) Seriously, though, thanks for the effort, and I look forward to trying it out once it's done. Most of my major concerns regarding packaging this stuff in a vendor-supported O/S are covered in the review request you linked to below. I will hit on a couple of key points:
-- 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. -- 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. -- One of the reasons why VGL is built somewhat statically is because it's an interposer. There are situations in which preloading VirtualGL into an application could override the application's dynamic link order. If an application links with libfoo dynamically and includes their own version of libfoo that differs from the system-supplied version, then preloading VirtualGL (which is dynamically linked against the system's libfoo) into the application could cause the application to use the system-supplied libfoo instead of its own. I am not suggesting to change anything-- just giving you stuff to watch out for. -- 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. -- 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. -- 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. Anything else you want to discuss, let me know. This is definitely the right place to discuss this. On 8/28/12 7:03 PM, Gary Gatling wrote: > Greetings VirtualGL developers, > > My name is Gary Gatling and I wanted to take a moment to introduce > myself. I work at NC State University with Red Hat Linux and I have an > interest in hybrid graphics notebooks due to owning two such systems. > > I submitted a VirtualGL package that was given to me by another fedora > packager to the fedora project because of bumblebee. (Yet another > package I am working on trying to get into fedora / epel) As I worked > with the process I had to make a few changes to conform to various > fedora packaging guidelines. But people were very helpful with this process. > > I am happy to say the package has been accepted into fedora and I have > requested an epel el6 branch as well! > > So soon fedora users will be able to do a "yum install VirtualGL" and it > will be installed. And once it builds in the el6 branch users of RHEL 6 > and clones who use the "epel" repository will also just be able to do a > yum install VirtualGL. (We have to get turbojpeg package from fedora > into el6 branch first but that should not take too long I hope) > > My review request for VirtualGL is at this URL: > https://bugzilla.redhat.com/show_bug.cgi?id=834127 > > Things just got "unstuck" today with all this due to a new mesa rpm in > fc18 and "rawhide." So now seemed a good time to contact you folks. > > I will stay on this mailing list going forward but also please let me > know if you guys have any questions or concerns about any of this? Also, > if there is some security issue or critical bug that comes up please let > me know (I assume that is one function of this list?) and I can deliver > a patch or new version when that happens to the fedora / epel build > system... > > The version that was packages is version 2.3.1. > > Hopefully this was the correct place to post this. > > 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 > ------------------------------------------------------------------------------ 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
