Bug#595928: python-mechanize: New upstream version available
Brian Sutherland
brian at vanguardistas.net
Mon Sep 13 10:49:57 UTC 2010
On Thu, Sep 09, 2010 at 04:09:17PM +0400, Mikhail Lukyanchenko wrote:
> 2010/9/9 Brian Sutherland <brian at vanguardistas.net>:
> > I reviewed the package you uploaded to
> > http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=python-mechanize
> > and have a number of questions/comments.
> >
> > 1. The upstream changelog [1] states for 0.2.0: "ClientForm has been
> > merged into mechanize. This means that mechanize has no dependencies
> > other than Python itself. ... I probably won't do further standalone
> > releases of ClientForm."
> >
> > So why does the package still depend on python-clientform?
> >
> > 2. Why does the package now have "XS-Python-Version: >= 2.6" in
> > debian/control and "2.5-" in debian/pyversions? At best that's
> > inconsistent.
> >
> > Upstream claims to support any python version above 2.4 [2]
> >
> > What's up?
>
> There's no reason for 1 and 2. Just dirty packaging.
Ok.
> > 3. Looking at the changelog of zope.testbrowser [3], it appears
> > incompatible with versions of python-mechanize above 0.2.0.
> >
> > A new zope.testbrowser version would have to be uploaded to
> > prevent breakage there. That may require changes elsewhere as the
> > differences between our current zope.testbrowser and the latest are
> > quite large.
>
> Indeed, current Squeeze version of zope.testbrowser should be
> incompatible with my mechanize upload. But I'm not sure how to resolve
> this issue because I have no experience with zope.
Treat zope.testbrowser just like any other python module for packaging
purposes.
In this case, I think you may be lucky zope.testbrowser has few other
hard dependencies. You might want to try just packaging the latest
version of testbrowser. You'll need to ask the pkg-zope mailing list if
there are any objections to this:
http://lists.alioth.debian.org/mailman/listinfo/pkg-zope-developers
> > 4. Squeeze is frozen [4]. Perhaps now is not the time to introduce
> > major new versions of packages that trigger breakage in other
> > packages? You need a very strong reasoning for that, what is it?
>
> You are absolutely right. As I was told at debian-mentors list I
> should have targeted this upload at experimental.
>
> > Given points 3 and 4, I'm afraid of uploading this package before
> > squeeze is released. Afterwards, it definitely should be uploaded along
> > with a new version of zope.testbrowser at least.
>
> I'll improve my package according to your comments 1 and 2 and then
> will have a look if I could package current zope.testbrowser release.
> But I'm afraid I have no sufficient expertise to deal with it.
You probably also want to look at other packages that depend on
python-mechanize. To see if they will be affected by the change.
AFAIK, the best way to search for reverse dependencies is using
"apt-cache rdepends".
The only one I know about off-hand is twill:
http://packages.debian.org/sid/python-twill
> It would be a shame if Debian stuck with outdated mechanize release.
Yes, it would be a shame. It's also a shame to ship with broken software
because of a last minute dependency change. I'll take old-but-working
software over broken software any time.
This version should have been uploaded a long time ago, before the
freeze. It would have been much easier.
> I
> currently develop mechanize-dependant project which I plan to
> distribute as Debian package. And I'm pretty sure it won't run with
> pre-0.2 mechanize.
Nice to see mechanize becoming widely used :)
Does your project have a name, btw?
--
Brian Sutherland
More information about the pkg-zope-developers
mailing list