Bug#710473: RFS: bats/0.2.0-1
Hi!
First and foremost thank you for thorough review.
On 06/17/2013 05:00 PM, Jakub Wilk wrote:
> (I don't intend to sponsor this package. Sorry!)
>
> * Grzegorz Niewisiewicz <grzegorz@niewisiewicz.pl>, 2013-06-16, 22:30:
>> http://mentors.debian.net/package/bats
>
> Direct link to .dsc for the lazy:
> http://mentors.debian.net/debian/pool/main/b/bats/bats_0.2.0-1.dsc
>
> Machine-readable d/copyright file specification reads: "There are many
> versions of the MIT license. Please use Expat instead, when it matches."
I didn't know that there are many variants of the MIT license. Changed
to Expat.
>
> Lintian emits:
> O: bats source: package-needs-versioned-debhelper-build-depends 9
> W: bats source: out-of-date-standards-version 3.9.3 (current is 3.9.4)
>
> But wait, why did you override
> package-needs-versioned-debhelper-build-depends? Lintian is correct
> here: your build-dependency on debhelper is insufficient.
Fixed. I didn't realize that I should declare a dependency on debhelper
whose version is at least the declared compatibility level. I declared a
dependency on debhelper (>= 9).
>
> If Lintian was a bit smarter, it would also emit
> hyphen-used-as-minus-sign for this line:
> .RI [ -c ] " file" ...
Fixed. What about the header? Currently it reads:
bats \- Bash Automated Test Suite
Do we want a hyphen or a minus here?
>
> Your README.source reads: "You WILL either need to modify or delete this
> file". So please do one of these things (probably the latter).
Ops, I totally missed that!
>
> The .orig.tar uploaded to mentors is not the same as uscan downloads:
> files in the former are owned by grn:grn; they are owned by root:root in
> the latter.
Done.
>
> Please remove the "Sample debian/rules that uses debhelper..." comment.
> It doesn't make sense.
Done.
>
> Please honour DEB_BUILD_OPTIONS=nocheck.
Done.
>
> I don't see a point of putting obvious things like "Added a watch file"
> to a changelog entry for an initial release. (Now if there was already a
> version in the archive without d/watch, and the file was added in a new
> version, that'd be another story.)
Done.
>
> Why does it need such a new version of coreutils? (This, on the other
> hand, might be something worth explaining in the changelog.) This
> build-dependency makes the package unbuildable on i386, which is stuck
> with an earlier version of coreutils.
I changed the dependency to coreutils from stable (>= 8.13-3.3).
>
> Also, why does it need such a new version of bash?
>
> Why priority "extra"? I'd use "optional".
>From the Debian Policy:
optional - (In a sense everything that isn’t required is optional, but
that’s not what is meant here.) This is all the software that you might
easonably want to install *if you didn’t know what it was and don’t have
specialized requirements*. This is a much larger system and includes the
X Window System, a full TeX distribution, and many applications. Note
that optional packages should not conflict with each other.
extra - This contains all packages that conflict with others with
required, important, standard or optional priorities, or *are only
likely to be useful if you already know what they are or have
specialized requirements* (such as packages containing only detached
debugging symbols).
So I assumed that a testing tools for developers are in the category of
specialized requirements.
I checked the practice in existing packages and I'm a little bit
confused. For example the packages python-nose (test discoverer and
runner) and libmysqlclient-dev are optional while python-mox (mock
object framework) is extra.
What's the rule here? I thought that you don't want to install
development tools unless you have specialized (i.e. programming) needs.
Regards
--
Grzegorz Niewisiewicz
Reply to: