[Pkg-dspam-misc] Bug#488924: dspam-webfrontend and apache2-suexec

[Stefan Fritsch]

Sorry this answer took so long.

First the usual disclaimer: I am not a release team member.

On Sunday 17 August 2008, Kurt B. Kaiser wrote:
> > Lenny is frozen, the release team will never accept so many
> > changes to go into Lenny.

> I understand your feeling about this.  However, I think you might
> be overly pessimistic, because the changes aren't as extreme as
> they might seem to be when looking at the changelog.

I still think that the release team will not accept this update. After 
all, they have to review the diff. And

 31 files changed, 605 insertions(+), 219 deletions(-)

is not easily reviewed, even if ~ 250 lines are documentation. But you 
can ask the release team yourself, if you don't believe me.

> I began with changes to pass the standard Debian flags to configure
> and to build in the source tree instead of in a subdir.  I did this
> so the Makefiles would be available when running maintainer-clean
> to remove the auto-generated files resulting from autoconf.  This
> produces a much cleaner .diff.gz, which now only contains entries
> from .../debian and its subdirectories, which is a goal when dpatch
> is used. This step was verified with interdiff.

This is exatcly the kind of change that should be deferred until 
lenny+1, IMHO.


> Fixing #481755 and #483868 involved one word changes to fix
> important regressions.  I think that inspecting the changes will
> show them to be non-problematic.

These should be included then.

> Updating to compatibility level 7 and Standards 3.8.0 introduced no
> additional changes.

If there are no changes necessary then it might be ok. But changing 
debhelper compatibility level is something I would avoid so close to 
the release unless you need the change.

> Adding amavis to the trusted users is a one word change to a config
> file, and non-disruptive by inspection.

No problem here.

> There were several changes to improve the documentation, and that's
> allowable per the Lenny freeze guidelines.

Yes.

> Now, the webfrontend: Previously, we had a non-functional demo
> VirtualHost fragment.  I moved it to its correct location in
> /etc/dspam/ and modified it to be served on localhost only, with a
> simplified login using htpasswd.  I also moved other files that the
> user might be expected to customize. Having a working website
> following installation should help those users who were having
> difficulty getting started with the webfrontend configuration.  I
> tested this by running the website.

This also looks like something that should better be deferred.

> There was an issue with upgrading etch: the /usr/share/dspam dir
> had some symlinks which were causing upgrade errors.  This is a
> serious bug, at least, and had to be fixed.

Yes.

> One of the Lenny goals is to pass the piuparts test.  The
> webfrontend was not purging correcty, and I made some changes to
> fix that.  The changes were most cleanly accomplished by putting
> the webfrontend config files under ucf control.

A less intrusive way would have been better, I think.

> There were no changes to the core of dspam or the webfrontend, so I
> don't think any of the above could be considered disruptive.

But all in all, it's quite a lot of change and there is plenty 
opportunity to introduce new bugs. This is something that should be 
avoided if possible.


Cheers,
Stefan