Bug#595928: python-mechanize: New upstream version available

[Brian Sutherland]

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