On Fri, 2012-09-07 at 16:54 -0400, Gary Gatling wrote:
Hello,
I am working on a package called
VirtualGL:
https://bugzilla.redhat.com/show_bug.cgi?id=834127
After contacting the upstream on their mailing list, they seem
obsessed with being able to install their own rprms and my package
together at the same time. This seems odd / bad to me since only one
vglrun could be in the path. He keeps talking about using symlinks
in /opt and so forth to to somehow make my package able to co-exists
with his package downloadable at:
That's not usually something Fedora does. The package name takes the
name of the upstream project, because the package *is* the delivery
option for that software in Fedora. We do not care that much about
upstream RPMs that random projects may distribute, because they are
often not tailored to the specifics of Fedora. We as Fedora packagers
are familiar with the requirements of Fedora, and if the upstream
project really wants control over the Fedora package, then they should
become Fedora packagers themselves.
Yes, you can use the 'alternatives' functionality, but that's mostly
only been used by completely different, competing implementations of the
same program, like Java vs. OpenJDK. It has not (nor, IMHO, should not)
be used to allow slightly different versions of the same project, which
isn't even forked (since you're just repackaging upstream code), to
coexist and be switched between.
My opinion, at least.
Dan
http://www.virtualgl.org/
He does want me to change the package name also. Is it too late for me
to that after that package has been accepted into fedora? Here is
what he says about that:
In terms of naming, I would suggest naming your RPM something besides
VirtualGL. If you are splitting it into multiple RPMs, then this is
easy. Just ship RPMs named "VirtualGL-common", "VirtualGL-client",
"VirtualGL-utils", "VirtualGL-server", "VirtualGL-devel",
etc., and
none
of them will actually be named "VirtualGL". Or maybe use
"VirtualGL-fedora" or some alternative (even lowercase "virtualgl",
perhaps.)
If a upstream project somehow objects to someone packaging their
software should you just give up and tell people that the upstream
would prefer you download their self created rpms or is it considered
acceptable to go ahead and package their software over their
objections?
He says at the end of his email:
"'I'm willing to help out in any way I can, within reason, but I will
also
re-iterate that VirtualGL was never really designed to be integrated
into an O/S distribution."
Thanks for any thoughts you guys might have about this surprising
reaction...