On 12/12/2011 07:15 PM, Toshio Kuratomi wrote:
On Mon, Dec 12, 2011 at 06:08:53PM +0100, Honza Horak wrote:
On 12/09/2011 10:01 PM, Tom Callaway wrote:
On 11/15/2011 03:19 AM, Honza Horak wrote:
If there are some license issues not easy to solve, there is still a
compat-gdbm package, which ships gdbm-1.8.3 with GPLv2+.
The problem is that compat-gdbm has no -devel package, and we cannot use
the gdbm-devel package for this.
Since Thorsten Kukuk is unwilling to relicense ypserv to resolve the
licensing conflict, we are left with the following options:
* Modify compat-gdbm to have a true -devel package (this will almost
certainly require namespacing it somehow, like "libgdbm_old.so")
I like this one, since it seems to be the easiest solution from my POV.
Be wary of making a quick estimate of the amount of work involved here.
Taking on a true compat-gdbm for this role means that you would be taking
over code that is no longer supported by upstream for an indefinite time
period. You would then be responsible for solving all bugs in the package
and fixing them yourself. There might also be a legal line that needs to be
observed here as the gdbm-1.8.x maintainer cannot use GPLv3+ code (the new
gdbm) to help make fixes to the GPLv2+ code so it may be that you actually
cannot maintain both packages yourself.... probably should discuss with spot
just what would be okay in this case.
To me, the easiest solution for you is probably going to be dropping ypserv
from the distribution. But if that's not possible, then attempting to
convince the gdbm upstream to switch back to GPLv2+ would likely be
a worthwhile investment.
I've asked gdbm upstream to do so, waiting for response right now.
Dropping ypserv isn't possible because there is no alternative for NIS
server.
Honza
But I don't see necessary to solve conflicts using renaming library and
header files. I'd rather just let compat-gdbm-devel and gdbm-devel
sub-packages to conflict (use "Conflicts:" explicitly), since it doesn't
make sense to me to have both packages installed at the same time (base
packages won't conflict). Then we don't have to change anything but
"Requires:" in packages like ypserv.
Please, let me know if you see any problems when solving that this way.
The Fedora Packaging Guidelines forbid this.
http://fedoraproject.org/wiki/Packaging:Conflicts
( IIRC, this was last revisited this year and it was decided that the
guideline should continue to prohibit Conflicts. You're welcome to bring it
up again but you would probably want to find the packaging meeting notes
where relaxing the conflicts guideline was discussed and be sure that you're
bringing new ideas to the table instead of rehashing the ones already
discussed.)
-Toshio
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
