Hi, On Tue, Mar 20, 2012 at 3:26 PM, Geoffroy Youri Berret <ef...@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, -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canvyna_on768-yq+ozbtf3mdd_mf+qn2qm7v70cuo+ndphg...@mail.gmail.com
