<div>Hey guys,<br><br></div><div>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)</div>
<div><br></div><div>Here is his response in full:</div><div><br></div><div><div>On Sun, Sep 9, 2012 at 12:38 AM, DRC <<a href="mailto:dcommander@users.sourceforge.net">dcommander@users.sourceforge.net</a>> wrote:</div>
<div>To be clear, I don't sell software. The official VirtualGL RPMs are</div><div>provided for free on SourceForge, but I pay my rent through support,</div><div>professional services, and funded development of VirtualGL and other OSS</div>
<div>projects (libjpeg-turbo, TurboVNC, libvncserver, etc. etc.) The ability</div><div>to do just-in-time distribution of binaries (via the VirtualGL</div><div>Pre-Releases page on VirtualGL.org) is part and parcel of these</div>
<div>professional services. A customer reports a bug, and I can often turn</div><div>around a new build for them within hours. These customers are typically</div><div>large installations-- sometimes hundreds of seats-- so when they get a</div>
<div>new RPM from me, they test it in isolation and then push it out to their</div><div>users via their own internal distribution mechanism. They would not use</div><div>YUM, even if VirtualGL was provided via that mechanism.</div>
<div><br></div><div>The VirtualGL Project has been shipping RPMs for 8 years now, so I'm</div><div>understandably hesitant to change the name of our packages just to make</div><div>a downstream O/S distributor happy. For consistency, I'd have to change</div>
<div>the name of all of the packages-- Windows, Mac, Debian, etc. PITA.</div><div><br></div><div>The concern is not really that Fedora will overwrite our RPMs. The</div><div>official VirtualGL RPMs use a build number based on the date (such as</div>
<div>20120908), so our RPMs will likely overwrite Fedora's, which use a build</div><div>number of 1, 2, etc. Using a higher epoch number with our packages is</div><div>certainly easy enough to do as well, to really guarantee that our</div>
<div>packages will clobber theirs. However, what I'm really trying to</div><div>achieve is the ability to install our package alongside the</div><div>distribution-supplied package. The idea is that a user may be using the</div>
<div>distribution-supplied version for day-to-day work, but they may need to</div><div>install a pre-release to test a new fix, or to temporarily use a</div><div>pre-release until a fix is deployed via YUM. It would be nice for them</div>
<div>to be able to do that without uninstalling the distribution-supplied</div><div>version. Also, the distribution-supplied version may support features</div><div>(such as OpenSSL) that we don't build into the official binaries.</div>
<div><br></div><div>I'm willing to meet halfway on this-- to move all of the official</div><div>VirtualGL files into /opt/VirtualGL and to use alternatives to install</div><div>links in /usr/bin. However, I'm not willing to change the name of the</div>
<div>package at this time, so if Fedora isn't willing to do that, either, or</div><div>if they aren't willing to play nice in /usr/bin, then a conflict is</div><div>inevitable. If a conflict is inevitable, then there's no real point to</div>
<div>me putting forth any effort to re-organize things on my end.</div><div><br></div><div>I'm still willing to make minor changes to make things easier on you, as</div><div>long as they don't make things harder on me. It would still be nice to</div>
<div>figure out how to pre-load the libraries from a non-system directory in</div><div>a generic way, for instance.</div><div><br></div><div>To answer your second question, no, I do not have time to become a</div><div>package maintainer. Frankly, what's in it for me? At the end of the</div>
<div>day, the only real benefit I would see from having VirtualGL distributed</div><div>by a major O/S is publicity, and the potential upside to that is not</div><div>worth the downside of completely re-engineering our packaging system. I</div>
<div>also do not want to get into the business of supporting</div><div>distribution-specific VirtualGL releases. I designed our official</div><div>packages to provide as uniform a layout as possible to make things</div><div>
easier on me. Trying to support several different distribution-specific</div><div>layouts makes things a lot harder for me.</div><div><br></div></div><div><br></div><div>So a question would be do I need to jump through more hoops so that:</div>
<div><br></div><div>" ...a user may be using the</div><div>distribution-supplied version for day-to-day work, but they may need to</div><div>install a pre-release to test a new fix, or to temporarily use a</div><div>
pre-release until a fix is deployed via YUM. It would be nice for them</div><div>to be able to do that without uninstalling the distribution-supplied</div><div>version. Also, the distribution-supplied version may support features</div>
<div>(such as OpenSSL) that we don't build into the official binaries." ?</div><div><br></div><div><div>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...</div>
</div><div><br></div><div>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. :)</div>
<div><br></div><div>Thoughts?</div><div><br></div><div><br></div>