Fw: RFS: python-coverage 3.0.1-1

[Luca Falavigna-4]

It seems my message didn't passed through, so I re-send it, I hope with
a better fate.



Data: Sat, 3 Oct 2009 11:43:25 +0200
Da: Luca Falavigna <dktrkranz@...>
A: Ben Finney <ben+debian@...>
Cc: debian-mentors@..., debian-python@...
Oggetto: Re: RFS: python-coverage 3.0.1-1


Hi Ben,

I reviewed a bit python-coverage, here are some suggestions:

debian/control:
* Build-Depend on debhelper (>= 7.3.5).

debian/python-coverage.dirs:
* Useless.

debian/python-coverage.install:
* I'd use debian/manpages to install python-coverage.1.

debian/rules:
* Why did you rename /usr/bin/coverage to /usr/bin/python-coverage?
* Pass --single-version-externally-managed to setup.py install.
* You could eventually adopt rules.tiny to simplify reading.

debian/watch:
* "Newest version on remote site is 3.1~b1, local version is 3.0.1",
   you could want to exclude beta releases.


--
  .''`.
 :  :' :   Luca Falavigna <dktrkranz@...>
 `.  `'
   `-

[Ben Finney-5]

Luca Falavigna <dktrkranz@...> writes:

> It seems my message didn't passed through, so I re-send it, I hope
> with a better fate.

We got it this time. Thank you for inspecting this package.

> debian/control:
> * Build-Depend on debhelper (>= 7.3.5).

The changelog entry for ‘debhelper’ 7.3.5 says:

  * python_distutils buildsystem: Build for all supported Python
    versions that are installed. Ensure that correct shebangs are
    created by using `python' first during build and install.
    Closes: #520834
    Also build with python*-dbg if the package build-depends
    on them.

What does it mean “if the package build-depends on them”? If “them”
means “debug packages”, why would any non-debug package depend on a
debug package?

> debian/python-coverage.dirs:
> * Useless.

I can't find where ‘/usr/bin/’ is excluded from requirement to be
created; is it in a part of Policy that I've overlooked?

> debian/python-coverage.install:
> * I'd use debian/manpages to install python-coverage.1.

Done.

> debian/rules:
> * Why did you rename /usr/bin/coverage to /usr/bin/python-coverage?

Because ‘/usr/bin/coverage’ is far too generic a name for a tool
specifically for checking Python source code. (This change was made
before I started maintaining the package, but I agree with it on this
rationale.)

> * Pass --single-version-externally-managed to setup.py install.

The package doesn't directly use ‘setup.py install’ at all, leaving that
to the various ‘debhelper’ programs. In what circumstances does a
package need your suggested change to override what those helpers do by
default?

> * You could eventually adopt rules.tiny to simplify reading.

That template omits the ‘.PHONY’ rules (marking some targets as phony so
they will be built regardless whether there is a file of the same name).
I think those rules serve a good purpose, so I use a ‘debian/rules’ file
that declares them.

> debian/watch:
> * "Newest version on remote site is 3.1~b1, local version is 3.0.1",
>    you could want to exclude beta releases.

I prefer to make this determination for each release, rather than have
them omitted by default. Is there a reason this is a bad practice?

Thanks again for your feedback.

--
 \      “Shepherds … look after their sheep so they can, first, fleece |
  `\   them and second, turn them into meat. That's much more like the |
_o__)      priesthood as I know it.” —Christopher Hitchens, 2008-10-29 |
Ben Finney

[Bernd Zeimetz]

Ben Finney wrote:

> The changelog entry for ‘debhelper’ 7.3.5 says:
>
>   * python_distutils buildsystem: Build for all supported Python
>     versions that are installed. Ensure that correct shebangs are
>     created by using `python' first during build and install.
>     Closes: #520834
>     Also build with python*-dbg if the package build-depends
>     on them.
>
> What does it mean “if the package build-depends on them”? If “them”
> means “debug packages”, why would any non-debug package depend on a
> debug package?

Checking if -dbg interpreters are installed is not enough to decide if you want
to buiid with them as you don't necessarily have a clean chroot. So dh needs to
look into the build-deps.

>
>> debian/python-coverage.dirs:
>> * Useless.
>
> I can't find where ‘/usr/bin/’ is excluded from requirement to be
> created; is it in a part of Policy that I've overlooked?

There is no need to use a .dirs file if setup.py creates the directory for you.


--
 Bernd Zeimetz                            Debian GNU/Linux Developer
 http://bzed.de                                http://www.debian.org
 GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
                   ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Ben Finney-5]

Bernd Zeimetz <bernd@...> writes:

> Ben Finney wrote:

> > I can't find where ‘/usr/bin/’ is excluded from requirement to be
> > created; is it in a part of Policy that I've overlooked?
>
> There is no need to use a .dirs file if setup.py creates the directory
> for you.

Gotcha. Okay, removed.

> > The changelog entry for ‘debhelper’ 7.3.5 says:
> >
> >   * python_distutils buildsystem: […] Also build with python*-dbg if
> >     the package build-depends on them.
> >
> > What does it mean “if the package build-depends on them”? […]
>
> Checking if -dbg interpreters are installed is not enough to decide if
> you want to buiid with them as you don't necessarily have a clean
> chroot. So dh needs to look into the build-deps.

Ah, I see. So this means it will check the ‘Build-Depends’ field for the
packages ‘python2.4-dbg’, ‘python2.5-dbg’, or ‘python-all-dbg’; nothing
to do with dependencies on ‘foo-dbg’. Right?

--
 \         “I call him Governor Bush because that's the only political |
  `\              office he's ever held legally.” —George Carlin, 2008 |
_o__)                                                                  |
Ben Finney


--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...