Re: Request For a Review: python-mpd2/0.4.1-1 [ITP]
Hi,
On Tue, Mar 20, 2012 at 3:26 PM, Geoffroy Youri Berret <efrim@azylum.org> wrote:
> Le 20/03/2012 17:00, Jakub Wilk a écrit :
>> Your Replaces is versioned but Conflicts is not. This is awkward.
>> What has changed in python-mpd 0.3.0 that Replaces is not needed
>> anymore?
>>
>> Is the conflict with python-mpd going to be permanent, or do you plan
>> removing the other package at some point? In the former case,
>> priority of one of the packages should be extra. (Policy §2.5:
>> “optional packages should not conflict with each other”.)
>
> First I thought python-mpd was abandoned, this is not true [0].
> Then I guess what I should do is to not to set python-mpd2 as replacing python-mpd, just conflicting.
>
> Then I'm not sure about the control file.
> "Priority: extra" for the source package and "Conflicts: python-mpd" for python2 package only.
> Is that right?
>
It looks like you originally intended to replace python-mpd with
python-mpd2, eventually removing python-mpd from the archive and
turning it into a transitional package or something like that. Have
you discussed this with the current python-mpd maintainers? If so,
report it in your RFS. If not, you'll have to go through that first.
Forks that simply suffix "2" are a really poor idea. If the
python-mpd2 project dies and later on python-mpd releases version 2.0,
we get into an ugly and confusing situation (take a look at the RPM
vs. RPM5 mess, for example). I recommend that you consider the
following:
* Is the python-mpd upstream unresponsive? It looks like Alexander
will stop actively maintaining python-mpd soon, but he doesn't support
the fork for a number of valid reasons that haven't been addressed in
this RFS.
* Does python-mpd2 have a reputable upstream? How long has it been
maintained by this new upstream? It looks to me like it was just
recently forked, and this is not a good sign.
* Do all Python-based clients work with python-mpd2? Have you actually
tested them?
At first glance, it seems hasty to replace python-mpd with python-mpd2
now. If I were you, I'd try to address those concerns, letting the
python-mpd2 upstream know about those concerns and doing some research
on the reasons behind this fork and the consequences of replacing
python-mpd.
And, above all, please talk to the current python-mpd maintainers if
you haven't done so yet. Unless they agree with this, you probably
won't be able to proceed.
>> Is there any reason for using a less liberal license for Debian
>> packaging than the one upstream uses?
>
> The only reason is that I want to keep the package as free as possible.
> I did not see any reason to use the same license as upstream, is there? (policy or strong convention I'm missing)
Yes, there is a very good reason. If you patch python-mpd2 and another
maintainer in the future attempts to merge your contributions into the
upstream project, he or she will be unable to do so due to the license
conflict.
So, unless you have a very good reason to use a more restrictive
license for your contributions, I'd highly recommend that you keep the
upstream license.
Regards,
Reply to: