On 8/30/12 11:09 AM, Gary Gatling wrote:
> -- 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 definitely suggest that, since you are already using a
non-system library path (/usr/lib[64]/VirtualGL) to store the faker
libraries, it makes more sense to also put the libGL.so symlinks there
instead of in a separate directory.
The question becomes how best to make vglrun find the faker libraries if
they are in a non-system path. After pondering the issue for a while, I
see a major hurdle, which is that the same vglrun script has to be able
to launch both 32-bit and 64-bit applications. The 32-bit and 64-bit
VirtualGL RPMs should be co-installable, so we can't have a different
version of vglrun in each. Further, if you are on a 64-bit machine, you
should be able to install or de-install the 32-bit VirtualGL RPM without
affecting your ability to run 64-bit apps. All of that makes it
minimally difficult, if not impossible, to create a version of vglrun
that has a hard-coded library path in it. If it was auto-generated with
the value of the VGL_LIBDIR CMake variable, then that would imply that
the script would be different between 32-bit and 64-bit builds, which
wouldn't work.
I think that, in your case, you could patch the vglrun script so that it
sets LD_PRELOAD to something like
/usr/lib64/VirtualGL/libdlfaker.so:/usr/lib64/VirtualGL/librrfaker.so:/usr/lib/VirtualGL/libdlfaker.so:/usr/lib/VirtualGL/librrfaker.so.
However, it would be nice to have a more generic solution. I note
that some applications will install libraries under
/usr/lib/{application}, even though the libraries are 64-bit. If we
assumed that VGL_LIBDIR would be the same between the 32-bit and 64-bit
packages, then we could get away with simply naming the faker libraries
differently (librrfaker32.so and librrfaker64.so, for instance) and
having vglrun pre-load
@VGL_LIBDIR@/lib*faker64.so:@VGL_LIBDIR@/lib*faker32.so. Still seems
inelegant, though.
Looking at another package (valgrind) that preloads libraries, it stores
the 32-bit and 64-bit interposers separately in /usr/lib/valgrind/ and
/usr/lib64/valgrind/, similarly to what you're doing, but I have no idea
how it determines which to load, since valgrind is a binary executable
and not a script. The same valgrind binary can be used to launch both
32-bit and 64-bit applications. On the surface, at least, this is the
same functionality we want with VirtualGL.
> -- 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."
Not likely to happen. For starters, all of my paying customers are
using RHEL, not Fedora, and the second most popular platform among VGL
users is Ubuntu. If I start relying upon external projects to provide
binaries for me, I run into all sorts of problems with differing user
experiences. VirtualGL has always been developed more as a product than
a project. I freely admit that it doesn't exactly follow the model of
most other open source projects, but you can find similarities in other
projects, such as VirtualBox and OpenOffice, that have a heritage as
commercial products (and also a heritage as Sun products, in both cases.)
The goal of our "official" binaries has always been to provide an equal
user experience across all platforms. Further, the purpose of the
in-tree packaging system is to make it easy for people (including me) to
generate binaries from a particular source revision, which makes it easy
to put proposed patches in front of users for testing. It takes time
for changes to propagate down through the various distribution
repositories, and that's just going to slow down the process of fixing
bugs. Further, I have no idea whether, at some point in the future,
Fedora may decide to freeze on a particular revision of VirtualGL (as
they have done with TigerVNC, for instance) or whether the maintainer of
the RPM may lose interest in the project, etc. The official binaries we
provide are an enterprise-class product, and I have to be able to stand
behind that product, because my sole source of income relies upon it.
Apart from providing an equal user experience, the other reason why we
tend to store things in /opt/VirtualGL is so vglconnect (the launcher
for the VirtualGL Client) knows where to find the binaries and scripts
on the server. This is important when using SSH tunneling, because it
has to know where to find vgllogin. If different platforms put vgllogin
in different places and don't provide a symlink under
/opt/VirtualGL/bin, then that means that the user always has to tell
vglconnect where to find vgllogin on whatever server it's connecting to.
If Fedora chooses not to provide that symlink, then so be it-- there
is a tacit understanding that they are choosing to support their version
of VirtualGL, and thus they are responsible for making it work with
whatever changes they make to it. For me, however, I can only stand
behind the packages I create. It would be nice to remove as many of the
/opt/VirtualGL hard-coded references as possible, but I don't know if
it's possible to get rid of all of them.
> 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.
Maybe, but then I also need to maintain an apt-get repository for the
Ubuntu users, which opens up a whole new can of worms. There are only
200 hours in the VirtualGL general fund each year to take care of
general project maintenance, community support, integrating patches from
the community, fixing bugs reported by the community, etc. I generally
run over that budget by about 100 hours each year, meaning that that
additional time is all pro bono. I'm OK with spending 30 or 40 hours on
something like a build system overhaul that ultimately allows me to
spend less time maintaining the project, but creating my own repos
ultimately is going to create more work for me, not less.
When I look to other open source projects as a model, OpenOffice is
notable. They have a similar distribution model to ours-- providing a
set of "cross-distribution" RPMs and DEBs. However, their "official"
RPMs and DEBs use a different name than the distribution-supplied
OpenOffice packages, and the "official" packages install everything
under /opt.
That seems like the best approach for us as well. If we can sort how
best to distribute the faker libraries under some subdirectory of
/opt/VirtualGL, then I am perfectly fine with putting everything under
/opt/VirtualGL and using alternatives to create symlinks in /usr/bin.
Ideally, your RPM would likewise register anything it installs in
/usr/bin via alternatives, allowing us to install both RPMs on the same
system.
In terms of naming, I would suggest naming your RPM something besides
VirtualGL. If you are splitting it into multiple RPMs, then this is
easy. Just ship RPMs named "VirtualGL-common", "VirtualGL-client",
"VirtualGL-utils", "VirtualGL-server", "VirtualGL-devel", etc., and none
of them will actually be named "VirtualGL". Or maybe use
"VirtualGL-fedora" or some alternative (even lowercase "virtualgl",
perhaps.)
> -- 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. :)
It's best to think of glx.h and glxext.h as internal headers to
VirtualGL. There is no easy way for me to modify the project to load
those headers from an external directory, nor would I want to, so if you
insist on doing so (why?), you're going to need to patch the source.
The reason why we provide our own versions of those headers is simply so
we can guarantee that there are valid prototypes for all of the
functions we interpose. Again, best to think of these as internal
headers. They are only used by the faker library.
This is another example of a knee-jerk reaction that the distribution
vendor is having to an automated test, without stopping to think about
what the test is really testing. What they're trying to prevent is an
application linking against its own in-tree static version of libGL.
Fair enough, but that's not what we're doing. VirtualGL provides an
implementation of the GLX API, just like Mesa provides an implementation
of the GLX API. The difference is that our implementation is loaded
into the application at run time rather than being linked in at compile
time. Mesa builds against its own internal GLX headers, and so do we.
The difference is that Mesa then installs their GLX headers, and we don't.
I would also add that we don't even really support Mesa as a back end,
and there are known interaction issues with, for instance, the Gallium
driver and VirtualGL. Thus, it may be the case that someone wouldn't
even be able to use VirtualGL with a "default" Fedora installation, and
there certainly isn't much point to it unless you have 3D hardware
acceleration (perhaps it works OK with nouveau, in which case you could
make that a dependency-- except that it would prevent you from later
uninstalling nouveau and installing the proprietary nVidia driver.)
> -- 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.
It is our standard to use variable names that are as short and
easy-to-remember as possible, and VGL_USE* is reserved for enabling
run-time features, not for build options.
> 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'm willing to help out in any way I can, within reason, but I will also
re-iterate that VirtualGL was never really designed to be integrated
into an O/S distribution, so this is all new to me as well.
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
