Re: Bug#599446: ITP: libapache2-mod-rivet -- Server-side Tcl programming system combining ease of use and power

[Massimo Manghi <mxmanghi@apache.org>]

Hi Julien

On 10/10/2010 02:44 PM, Julien Viard de Galbert wrote:
> Hi all,
> First accept my apologies for not responding to the list in the first
> time (while I intended to) and only CCing now...
>
>    

not a problem, I'm answering this message on the list
> > I thought the same at first, but I could not explain the fact the debhelper
> > was evidently missing in an environment devised to build packages. In fact, as
> > soon as I got it into base.tgz something changed, the depends were detected
> > and the package built.
> >
> >      
> I believe debhelper is not mandatory, packaging can be done without it
> so pbuilder should not include it by default.
>
> I understand that installing it changes things for you, this looks
> strange. But I'll have to test it to be able to comment on that...
> (still seeking expert advice...)
>
>    

I thought the debhelper dh_* scripts were the basics of packaging. They 
are ubiquitous in the docs when the debian/rules files is explained.

> I've never done this (I'm running a sid workstation for my packaging
> work) but I remembered reading about it. So I searched in the archives
> and could recover this two mails:
>   http://lists.debian.org/debian-mentors/2010/08/msg00135.html
>   http://lists.debian.org/debian-mentors/2010/05/msg00129.html
>
> Also pbuilder include some example hooks that might worth a look, especially:
>   /usr/share/doc/pbuilder/examples/B90lintian
>
>    

that's exactly what I needed. I managed to run 'lintian' within pbuilder 
and it brought up several inconsistencies. I fixed almost all of them 
now. Only 3 of them remain

W: libapache2-mod-rivet source: changelog-should-not-mention-nmu
W: libapache2-mod-rivet source: configure-generated-file-in-source 
config.log
W: libapache2-mod-rivet source: configure-generated-file-in-source 
config.status

AFAIK I can't strictly fix the first because I'm not a maintainer. A 
sponsor could easily repackage it fixing the changelog. The 2 files 
related to configure could be removed tweaking the contents of the 
source tree. If not strictly necessary I would put it off for a 2.0.1-2 
version of the package.

thanks

 -- Massimo