upstream wants me to rename my package

[Mattia Verga]

Renaming just the package doesn't solve problems of conflicting files. 
Libraries and binaries provided by the two packages will have the same 
name, so it's not possible to have both installed beacuse one conflicts 
with the other.

The idea of just "install a pre-release version without uninstalling the 
distribution-supplied version" seems odd to me.

Someone with more experience in rpms than me can correct my assumptions 
if I'm wrong.

Il 09/09/2012 08:03, Gary Gatling ha scritto:
> 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 
> <mailto: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/823cfe6e/attachment.html>