upstream wants me to rename my package

[Gary Gatling]

Hey guys,

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)

Here is his response in full:

On Sun, Sep 9, 2012 at 12:38 AM, DRC <dcommander at users.sourceforge.net>
wrote:
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.


So a question would be do I need to jump through more hoops so 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." ?

So I guess another question is what is our official response?  I am trying
to follow Ken's suggestion but anything I say just makes him more insistent
and possibly hostile...

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. :)

Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120909/908d5aa9/attachment-0001.html>