Hi Daniel, On Sat, 13 Jul 2013 18:59:34 +0200, Daniel Augustin Pavel <daniel.pa...@gmail.com> wrote: > On 13 July 2013 18:26, Stephen Kitt <sk...@debian.org> wrote: > > Here is my review of the package so far: > > * great job on the ConsoleKit / systemd support, with minimal debconf > > prompting, nice! > > Thank you! I'm also packaging Solaar for Ubuntu, and I'm trying to > have it integrate nicely with "modern" destktop environments. At the > same time, some users might have a lightweight DE, and I don't want to > force on them such heavy dependencies. > > I fear the notification about using the plugdev group may be a bit too > much, but I don't know how to handle this situation better.
Neither do I, and in most cases users won't see it anyway.
> > * personally I'd drop substvars.extra (and define the substvars in
> > debian/rules, with a solaar: prefix) and rules.extra, but that's really
> > a question of preference rather than best practice as far as I'm concerned
>
> I'm using the substvars because the Ubuntu package needs
> gnome-icon-theme-full (or equivalent).
> By defining them in debian/rules, you mean something like
> "dh_gencontrol -- -Vsolaar:VAR=VALUE" ?
Yes. To handle the differences between Ubuntu and Debian, you could use the
approach used in gcc's packaging for example:
* build-depend on lsb-release
* add something like this to debian/rules:
distribution := $(shell lsb_release -is)
...
ifeq ($(distribution),Ubuntu)
...
else
...
endif
> The rules.extra was actually needed by some silliness I was doing with
> the Ubuntu package; I've gotten rid of it but forgot to remove
> rules.extra.
OK.
> > * why not use dh compat level 9?
>
> I have no idea what that is :). Most likely compat 8 is what I found
> in the samples I used when I started packaging. What's the
> difference/impact?
Have a look at the "COMPATIBILITY LEVELS" section in debhelper's man page for
all the details; in your case, compat 9 avoids having "--with=python-support"
by default.
> > * since this is a new package, you should file a separate ITP (alongside
> > this RFS), indicate that the RFS blocks the ITP, and close the ITP in
> > debian/changelog (not the RFS, I'll do that when I sponsor the package)
>
> Okaaay... I'll do this slowly so I don't get confused :). Sorry, I'm
> still learning the maintaining/sponsorship process.
No problem! Filing an ITP means "I'm working on packaging this", and
hopefully avoids duplication of effort. The Debian package effectively fixes
the "bug", so the changelog indicates that with the appropriate bug number.
Filing an RFS mean "I need help getting this uploaded"; the package can't fix
that bug, so it's not mentioned in the changelog.
> > * in debian/copyright, you need to give the license paragraphs for the SVG
> > and PNG files, in the same way as your GPL-2 license paragraph; "These
> > files were copied from the Oxygen icon theme" should go in a Comment:
> > stanza
> > * still in debian/copyright, you don't need "Copyright (C)" in your
> > Copyright: stanzas (so just "Copyright: 2012-2013 Daniel Pavel")
>
> Okay.
>
> > Outwith the Debian-specific packaging, you should add appropriate headers
> > to your source files in bin and lib, as described in the "How to Apply
> > These Terms to Your New Programs" at the end
> > of /usr/share/common-licenses/GPL-2.
>
> Okay. I've seen some software including the copyright template at the
> beginning of source files, but I'm lazy and hoped the COPYING file in
> the sources would cover it :). Is it necessary to include it in _all_
> sources, or just the bin/ and lib/ root?
Ideally it should be in all the sources. It may seem unnecessary when you
think of your piece of software as a whole, but it means that if someone else
picks one or two files from Solaar for use elsewhere, the licensing terms for
those files stay with them. It avoids future packagers tearing their hair out
trying to determine the correct licensing information for packages with
sources pulled from a variety of different projects...
Regards,
Stephen
signature.asc
Description: PGP signature
