New source package: ginn

Ok, so, here is some things that needs to be fixed from the current package:

* 0.2.3-0ubuntu1-1 isn't a good versionning (should have two - as it's only the latest one which is taken). It should be 0.2.3-0ubuntu1.

* looking at how you handle conffilles in 0.2.3-0ubuntu2, it's not the right way to do that for various reason. A good reference is to look at http://wiki.debian.org/DpkgConffileHandling.
I strongly recommend looking at "Warning: since dpkg 1.15.7.2 this can be done using dpkg-maintscript-helper (see its man page for details). Please use that tool instead of copy/pasting yet another version of this snippet in the Debian archive." (we have this version of dpkg now).
However you'll need to add this to debian/control to the binary package: Pre-Depends: dpkg (>= 1.15.7.2)
to ensure people upgrading from lucid to next LTS get the right dpkg version configured on their new system before it tries to handles that package (lucid does have an earlier dpkg version).

* debian/copyright: the format changed slightly, please refer to libunity package (http://bazaar.launchpad.net/~ubuntu-desktop/libunity/ubuntu/view/head:/debian/copyright) to have the latest syntax. In addition, it referts to LGPL-3 whereas the package is GPL-3.

* debian/rules is weird and the debian/ginn.install is weird. You are installing in debian/tmp, then listing all the file and check that you listed all the files. You don't need that as you only have one package. So removing the .install file, the overrides in debian/rules will achieve exactly the same in an automagic manner.

* debian/control: please add the Vcs-Bzr tag. In addition to this (but that will be as well for all utouch packages), we try to set bzr right according to upload privilege. This mean that a core dev (as it will be in main in the future), can't update the packaging branch.
For instance, in unity and other gnome components, we have it in the ~ubuntu-desktop team where all core-devs are part. Similar thing with compiz and ~compiz team. Maybe you should do a utouch-packagers team so that core dev can commit there?

Otherwise, the remaining part looks fine :)

I think I need clarification on how the maintainer scripts in 0.2.3-0ubuntu2 are not doing the right thing. The dpkg-maintscript-helper script is only useful for renaming or removing conffiles, and neither operation applies in this case. It is not for basic installation or purge operations as clearly outlined in the Debian Policy Manual, section 10.7.3.

If the maintainer scripts in 0.2.3-0ubuntu2 do not conform to the Debian Policy Manual in some way or if Ubuntu packaging policy contravenes Debian policy regarding the installation and purging of conffiles, I would like to have an online reference to follow for the future.

debian/postrm:

ginn_config_dir=/etc/ginn

purge_config()
{
  rm -rf $ginn_config_dir
}

case $1 in
  purge)
    purge_config
    ;;
  *)
    ;;
esac

exit 0

-> You are clearly removing a conffiles in that file. I really wonder why you are creating them in postinst rather than copying it in a .install?
That mark the file as not being a conffile by the dpkg system from what I know.

Again, it's more best practice than nothing else. Doing that manually, I can't ensure you that the package will be acked in main.

As outlined in the previous reference, the right way is to follow http://wiki.debian.org/DpkgConffileHandling
and ship conffiles referenced in .install file (it can copy it from another directory even) to ensure that it's marked as a conffiles by dpkg during package creation.

The procedure in http://wiki.debian.org/DpkgConffileHandling applies only to packages that remove or rename an existing conffile. This package does neither. I can see no way of integrating a conffile removal or rename operation into this package.

The removal-on-purge of the configuration file in the postrm maintainer script is performed structly in accordance with the Policy Manual, section 10.7.3 (http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ch-files.html#s10.7.3), which is as follows.

"The other way to do it is via the maintainer scripts. In this case, the configuration file must not be listed as a conffile and must not be part of the package distribution. If the existence of a file is required for the package to be sensibly configured it is the responsibility of the package maintainer to provide maintainer scripts which correctly create, update and maintain the file and remove it on purge. (See Package maintainer scripts and installation procedure, Chapter 6 for more information.) These scripts must be idempotent (i.e., must work correctly if dpkg needs to re-run them due to errors during installation or removal), must cope with all the variety of ways dpkg can call maintainer scripts, must not overwrite or otherwise mangle the user's configuration without asking, must not ask unnecessary questions (particularly during upgrades), and must otherwise be good citizens. "

The reasons for choosing the non-conffile method of configuration file packaging are outlined in Appendinx E of the policy manual (http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ap-pkg-conffiles.html).

If a Ubuntu package is rejected for strictly following published Ubuntu policy, perhaps the published policy should be changed to reflect the reality.

OK, I converted /etc/ginn/wishes.xml to a conffile (we'll just have to live with noise on upgrades). All of the other changes have also been made.

Stephen,

please keep in mind that people reviewing don't have as much knowledge as you have on your package and upstream. So don't be harsh please and give some context.

I wasn't aware at all that the content of those files was host specific, and so I understand now why you didn't want them to be a conffiles. In that case, your rationale makes totally sense. Please revert it.

being explicit is always better than being implicit… help the reviewer giving some context is also another way of helping the review to speed up…

ok, all is now done, and after talking to Stephen about the noise issue and such, seeing that upstream prefer that way as well, and having the assurance that the changes will be in next release (it's an import from upstream), pushing it now to ubuntu and NEW.