Fedora Account System
Red Hat Associate
Red Hat Customer
Spec URL: http://www.annexia.org/tmp/ocaml/mldonkey.spec SRPM URL: http://www.annexia.org/tmp/ocaml/mldonkey-2.9.3-1.fc9.src.rpm Description: MLDonkey - the Open Source eDonkey client Features: * 100% OpenSource, GPL license * runs on Linux, Unix, Solaris, MacOSX, MorphOS and Windows * Core and Guis are separated or linked. * written in ObjectiveCaml, with some C and even some Assembler parts. * OtherNetworksSupported, using separate executables * built to run as daemon for days, weeks, ever...
Added magic word ocaml to the summary.
I should add that there are problems with the %doc section revealed by rpmlint which I'm going to sort out.
BTW the legal status of MLDonkey is stil questionable - I asked Tom Callaway some time ago and he didn't provides clean answer whether we may distribute p2p-software such as MLDonkey, aMule etc. We already have almost finished package at Livna's bugzilla: http://bugzilla.livna.org/show_bug.cgi?id=1487 but its obvious that shipping MLDonkey in main Fedora repo will be preferred. The only thing is left is to fix config-files so we could simply use generic make install instead of manually copying files with install tool.
The legal status of the software itself or the legal status of distributing p2p software? There can't be a problem distributing p2p software generically because otherwise Fedora wouldn't come with useful tools such as bittorrent, wget, scp, or cp. I don't see an issue with the license of mldonkey itself. If you want the work done to be part of Fedora, you'll need to post candidate spec and SRPM URLs to this bz.
(In reply to comment #3) > BTW the legal status of MLDonkey is stil questionable - I asked Tom Callaway > some time ago and he didn't provides clean answer whether we may distribute > p2p-software such as MLDonkey, aMule etc. > > We already have almost finished package at Livna's bugzilla: > > http://bugzilla.livna.org/show_bug.cgi?id=1487 > > but its obvious that shipping MLDonkey in main Fedora repo will be preferred. > > The only thing is left is to fix config-files so we could simply use generic > make install instead of manually copying files with install tool. > Fedora already contain that kind software. DC++ https://admin.fedoraproject.org/pkgdb/packages/name/valknut torrent's https://admin.fedoraproject.org/pkgdb/packages/name/bittorrent
In my view, the two potential maintainers (Richard and Peter) need to co-ordinate their work to be co-maintainer of the package. (either in livna or Fedora). @Richard As your are the ocaml maintainer in Fedora, your interest in mldonkey is valuable. And as such, the ocaml-find-requires.sh requirement is an important improvement. So thx for trying to solve this. But lot of work is missing (and as already be done in the Peter's spec). As such, if I would review this package, I would just put a "-", with the reason "Not enought work to review". Actually the potential reviewers that has already been involved in the mldonkey review, wouldn't play with reviewing the same package twice. If you can find a reviewer that could review the package from the start, I will have nothing about this. So please co-ordinate with Peter work. And I hope you understand my point of view. @Peter As I said from the livna review, some dependencies are still missing to just work normally after a yum install. Either you or Richard, need to be the primary maintainer of the package. You need to solve this together even if you may not know each other very well for now. So please start proposing things...
Reply to comment 6: I think we should ditch my package and go with the livna one (but in Fedora, so the spec & SRPM copied here and adjusted if necessary for any Fedora policy). ocaml-find-provides/requires aren't really necessary because mldonkey doesn't have any OCaml library component (AFAIK). I don't mind being maintainer or co-maintainer if one is needed.
Since no one can be bothered to update this BZ, despite the desperate importance of mldonkey to the future of Fedora, I'm closing it.
Too bad. Well, maybe when Peter finds some free time, we can revisit this.