Red Hat Bugzilla – Bug 433143
Review Request: mldonkey - MLDonkey is a multi-platform multi-network peer-to-peer client (ocaml)
Last modified: 2008-04-04 16:39:20 EDT
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
MLDonkey - the Open Source eDonkey client
* 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:
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
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
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:
> 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.
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
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
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.