I decided to ask if he would be willing to add an epoc tag as
Ken suggested or be willing to become a maintainer or
co-maintainer. I think he just continues to insist that rpm work
in a way its not designed... (Have two versions of the same
software thing on a box)
To be clear, I don't sell software. The official VirtualGL
RPMs are
provided for free on SourceForge, but I pay my rent through
support,
professional services, and funded development of VirtualGL
and other OSS
projects (libjpeg-turbo, TurboVNC, libvncserver, etc. etc.)
The ability
to do just-in-time distribution of binaries (via the
VirtualGL
Pre-Releases page on VirtualGL.org) is part and parcel of
these
professional services. A customer reports a bug, and I can
often turn
around a new build for them within hours. These customers
are typically
large installations-- sometimes hundreds of seats-- so when
they get a
new RPM from me, they test it in isolation and then push it
out to their
users via their own internal distribution mechanism. They
would not use
YUM, even if VirtualGL was provided via that mechanism.
The VirtualGL Project has been shipping RPMs for 8 years
now, so I'm
understandably hesitant to change the name of our packages
just to make
a downstream O/S distributor happy. For consistency, I'd
have to change
the name of all of the packages-- Windows, Mac, Debian,
etc. PITA.
The concern is not really that Fedora will overwrite our
RPMs. The
official VirtualGL RPMs use a build number based on the
date (such as
20120908), so our RPMs will likely overwrite Fedora's,
which use a build
number of 1, 2, etc. Using a higher epoch number with our
packages is
certainly easy enough to do as well, to really guarantee
that our
packages will clobber theirs. However, what I'm really
trying to
achieve is the ability to install our package alongside the
distribution-supplied package. The idea is that a user may
be using the
distribution-supplied version for day-to-day work, but they
may need to
install a pre-release to test a new fix, or to temporarily
use a
pre-release until a fix is deployed via YUM. It would be
nice for them
to be able to do that without uninstalling the
distribution-supplied
version. Also, the distribution-supplied version may
support features
(such as OpenSSL) that we don't build into the official
binaries.
I'm willing to meet halfway on this-- to move all of the
official
VirtualGL files into /opt/VirtualGL and to use alternatives
to install
links in /usr/bin. However, I'm not willing to change the
name of the
package at this time, so if Fedora isn't willing to do
that, either, or
if they aren't willing to play nice in /usr/bin, then a
conflict is
inevitable. If a conflict is inevitable, then there's no
real point to
me putting forth any effort to re-organize things on my
end.
I'm still willing to make minor changes to make things
easier on you, as
long as they don't make things harder on me. It would
still be nice to
figure out how to pre-load the libraries from a non-system
directory in
a generic way, for instance.
To answer your second question, no, I do not have time to
become a
package maintainer. Frankly, what's in it for me? At the
end of the
day, the only real benefit I would see from having
VirtualGL distributed
by a major O/S is publicity, and the potential upside to
that is not
worth the downside of completely re-engineering our
packaging system. I
also do not want to get into the business of supporting
distribution-specific VirtualGL releases. I designed our
official
packages to provide as uniform a layout as possible to make
things
easier on me. Trying to support several different
distribution-specific
layouts makes things a lot harder for me.
pre-release until a fix is deployed via YUM. It would be nice
for them
version. Also, the distribution-supplied version may support
features
My suggestion is that we name the package "virtualgl" (all
lowercase) since thats still technically the name of the
software. I think caps are kind of stupid in a package name
anyways? I'm not sure what to say about "alternatives" but I'm
not trying to piss them off either. :)
