VirtualGL packaging blockers for Debian (and Ubuntu proper)

[Vincent-C]

I've finally had a chance to take a look at the current virtualgl packaging in the PPA, and so I've made a laundry list of issues with the current packaging that I'm not entirely sure how to address / I don't understand...

• "virtualgl-libs" installs a set of libraries (libdlfaker.so, libgefaker.so, librrfaker.so), each without a versioned soname, directly into /usr/lib/$DEB_HOST_MULTIARCH. AFAIU, to comply with Debian Policy, they'd have to be properly versioned if placed in a public shared library directory (and package name has to match the soname of that library). Or we could install them in some subdir of /usr/lib/$DEB_HOST_MULTIARCH like we do with primus-libs?
• the "virtualgl" package contains header files? (/usr/include/rr.h, /usr/include/rrtransport.h) If they're actually needed, we'd have to split them up into a separate -dev package
• the "virtualgl" package installs /usr/bin/.vglrun.vars64, which is not an executable (and stuff in $PATH all have to be executables). What is this file / would anything break if it's moved away from /usr/bin?
• debian/rules: if the value of FAKELIBDIR depends on what arch we're building(?) on (shouldn't we be using DEB_HOST_ARCH instead of DEB_BUILD_ARCH?), why not use the multiarch triplet for that particular arch, instead of hardcoding "64" for amd64 like we currently do now? Even if it makes sense for i386/amd64, what about arm/arm64 or ppc/ppc64 combos?
• debian/copyright is woefully incomplete

[Vincent-C]

Oh, and we're missing a whole slew of manpages, but that's not actually a blocker.

[Lekensteyn]

• virtualgl-libs will never be versioned. Programs do not link to these libraries, instead they load these libraries using LD_PRELOAD via the vglrun shell script.
• header files: Those are not used by us at least.
• /usr/bin/.vglrun.vars64 is new since 2.3.3, it contains search paths for the virtualgl libraries which is used by vglrun. Since a /usr/lib/$DEB_HOST_MULTIARCH is used in the vglvars file and present in the default ld search path, these file can safely be removed.
• about FAKELIBDIR, I agree that it has not been thought out for other architectures. Its use of DEB_BUILD_ARCH was probably done because of insufficient knowledge. It should be safe to use /usr/lib/virtualgl/fakelib/$(DEB_HOST_MULTIARCH) instead (or something similar). The FAKELIBDIR file will contain the libGL.so symlink to librrfaker.so that intercepts library calls, so it must not be installed to /usr/lib or similar. It doesn't seem to be used by Bumblebee though, upstream provides it for certain applications.
• What is incomplete about debian/copyright?
• [additionally:] the HTML documentation may refer to hard-coded paths in /opt/, you may have to patch that.

While packaging, also consider non-Bumblebee use of virtualgl. For example, I use it now to run an Android emulator on a remote desktop (LAN) because of resource constraints of my laptop.