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 <dcomman...@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?
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
