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. On 9/8/12 6:02 PM, Gary Gatling wrote: > > > On Fri, Sep 7, 2012 at 4:30 PM, DRC <dcomman...@users.sourceforge.net > <mailto:dcomman...@users.sourceforge.net>> wrote: > > > Just want to check two things with you. > > "With VirtualGL, if the main concern is that Fedora's RPMs will > overwrite the ones that he sells, could they just bump the Epoch tag in > their copies?" > > I didn't think you would like that suggestion but I wanted to ask first? > > Second, Would you be interested in becoming the maintainer or > co-maintainer of this package in fedora? You seem to have many > objections to the packaging guidelines? > > Just wanted to get answers to these two questions before trying to go > further because there is some blowback to changing the package name and > these were suggested as alternatives you would like? > Thanks so much, > > > ------------------------------------------------------------------------------ > 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 > VirtualGL-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/virtualgl-devel > ------------------------------------------------------------------------------ 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 VirtualGL-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
