[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#683120: RFS: yadifa/1.0.3-1 [ITP]



On 2014-04-09 09:26, Markus Schade wrote:
> thanks for the review, Christian!

Glad I can help :-)

Here is some further feedback:

>> debian/control
>> ==============

>> If you're using a VCS for your packaging, Vcs-* URLs would be nice (to
>> simplify contributing to your packaging). You can also use
>> Debian's infrastructure, see [1].

Almost correct. The Vcs-Git URL should use the git:// protocol
specifier, and you could add a Vcs-Browser URL pointing to the github
package, like so:

  -Vcs-Git: https://github.com/asciiprod/yadifa.git
  +Vcs-Git: git://github.com/asciiprod/yadifa.git
  +Vcs-Browser: https://github.com/asciiprod/yadifa

> I had intended to set up a repo after the first upload. But of course it
> is easier to contribute even before that. And since I need a DM approval
> for an Alioth repo, I settled for github for now.

I don't think you need DM approval, you only need a DD to request access
for you (which would probably be the DD sponsoring your package).

But github is more than fine for now, you can always switch later (or
not at all).

>> You're providing static libraries in the -dev package, but not a shared
>> library package. This is not necessarily wrong, just unusual. Note
>> that the configure script has an option to build a shared library.
> 
> Good point. The default was to do static linking. Now with shared libs,
> I have not just two packages but five (three just for the libs). But as
> the recent openssl bug shows, it is easier to just patch a lib than to
> rebuild all depending packages.

Looks good! One major issue though: the libraries are definitely not
Priority: standard :-) (= part of the default Debian installation). You
can simply remove this line, the inherited "optional" is fine.

nit-pick #1: the synopsis refers to Yadifa twice, in different case, and
the other parts should be lowercased. According to the Developer's
Reference[0], something like this would probably be more appropriate:

  -Description: Yadifa DNS Core Shared Library used by YADIFA
  +Description: DNS core shared library used by YADIFA

I like your approach with a common description provided through a
substitution variable! Very efficient.

nit-pick #2: The package descriptions of the libraries could be a bit
more explanatory. (lintian also complains about this). Currently, they
basically just repeat the synopsis. Try to describe what another user of
the library can do with this package. For example, for libdnszone0,

  This library can be use to read and write YADIFA-compliant zone files
  and [...]

(I'm just guessing that, I didn't look). This is much more informative
to developers who might be interested in writing eg GUI client for
modifying zone files. Same goes for the other two libs.

Finally, my personal taste for the package description would be
something like

  - This package contains archive-style libraries and header files for
  - libdnscore0, libdnsdb0 and libdnszone0
  + This package contains the header files and the static libraries
which are
  + needed for developing YAFIDA applications.

but that's highly subjective.

>> debian/copyright
>> ================
> 
> I had originally just included upstreams COPYING, but I think it's safe
> to extend the years to include all changes from upstream since then.
> 
> As for my own packaging, I don't mind putting it under a BSD-style license.

Just to clarify: you don't have license all of your packaging under a
BSD-style license., it's sufficient to do that just for the files in
debian/patches/*. The machine-readable copyright format specification[1]
has more details.

> So again, after making these various adjustments and corrections, I have
> re-uploaded the package again.

By the way, if you can't find a sponsor here (it sometimes takes a
while), you can also try pinging either people or teams who might be
interested in your package (eg other DNS maintainers).

Finally, here are some ideas for future versions of your package:
  * build a -dbg package (debhelper can automate lots of this)
  * provide *.symbols files
  * Multi-archification

I say future versions because the value added isn't that big, and when
you've just begun packaging then all this stuff in total can easily
become overwhelming.

Good luck with your package :-)

Christian

> To access further information about this package, please visit the
> following URL:
> 
> http://mentors.debian.net/package/yadifa
> 
> Or via dget at
> 
> http://mentors.debian.net/debian/pool/main/y/yadifa/yadifa_1.0.3-1.dsc

[0]
file:///usr/share/doc/developers-reference/best-pkging-practices.html#bpp-pkg-synopsis

[1]https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/		


Reply to: