Re: forked library
On Fri, 2012-11-30 at 20:16 +, Richard W.M. Jones wrote: On Fri, Nov 30, 2012 at 09:07:34PM +0200, Nikos Roussos wrote: Hi, I maintain IDJC [1], which depends on libshout. The latest version though depends on libshout-idjc a fork of the original library, since the idjc upstream developer wanted some extra functionality on libshout and didn't want to wait for libshout upstream to adopt his changes. I've read the relevant documentation [2] but I'm not sure what's the best way to proceed. The good thing that he doesn't bundle his version of libshout, but instead he has made it a separate release [3], which could also be packaged for Fedora. But a fork is a fork. Should I just make a request for exception and package the forked library or should the package be orphaned? [1] https://apps.fedoraproject.org/packages/idjc [2] https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries [3] http://sourceforge.net/projects/idjc/files/ How likely is it that the changes would go back into libshout? Is the maintainer of IDJC pushing them? Is the libshout maintainer interested in them? After discussing it with the developer it seems that some of his changes include support for non-free codecs (eg. AAC). So the best solution I can think of is to orphan the package and then move it along with libshout-idjc to RPMFusion. -- Nikos Roussos comzeradd @ freenode.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: forked library
On Fri, Nov 30, 2012 at 1:07 PM, Nikos Roussos comzer...@fedoraproject.orgwrote: ** Hi, I maintain IDJC [1], which depends on libshout. The latest version though depends on libshout-idjc a fork of the original library, since the idjc upstream developer wanted some extra functionality on libshout and didn't want to wait for libshout upstream to adopt his changes. I've read the relevant documentation [2] but I'm not sure what's the best way to proceed. The good thing that he doesn't bundle his version of libshout, but instead he has made it a separate release [3], which could also be packaged for Fedora. But a fork is a fork. Should I just make a request for exception and package the forked library or should the package be orphaned? I don't think you need a bundling exception if there's no bundling. We can have both the fork and the original in the distro, I believe. -J [1] https://apps.fedoraproject.org/packages/idjc [2] https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries [3] http://sourceforge.net/projects/idjc/files/ -- Nikos Roussos http://roussos.cc comzeradd @ freenode.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: forked library
On Fri, Nov 30, 2012 at 09:07:34PM +0200, Nikos Roussos wrote: Hi, I maintain IDJC [1], which depends on libshout. The latest version though depends on libshout-idjc a fork of the original library, since the idjc upstream developer wanted some extra functionality on libshout and didn't want to wait for libshout upstream to adopt his changes. I've read the relevant documentation [2] but I'm not sure what's the best way to proceed. The good thing that he doesn't bundle his version of libshout, but instead he has made it a separate release [3], which could also be packaged for Fedora. But a fork is a fork. Should I just make a request for exception and package the forked library or should the package be orphaned? [1] https://apps.fedoraproject.org/packages/idjc [2] https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries [3] http://sourceforge.net/projects/idjc/files/ How likely is it that the changes would go back into libshout? Is the maintainer of IDJC pushing them? Is the libshout maintainer interested in them? Because if it's the case that these changes are likely to go into libshout, then carrying them as %patches in the Fedora libshout package might be a better idea. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
