Your message dated Mon, 6 Jul 2015 11:22:15 +0200
with message-id <20150706092215.ga30...@mail.beuc.net>
and subject line Re: Bug#789772: don't blame piuparts if you violate policy
has caused the Debian Bug report #789773,
regarding fusionforge-shell: modifies conffiles (policy 10.7.3): /etc/pam.d/sshd
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
789773: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789773
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: fusionforge-shell
Version: 6.0.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Hi,
during a test with piuparts I noticed your package modifies conffiles.
And this is not even a conffile shipped by your package.
This is forbidden by the policy, see
https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
10.7.3: "[...] The easy way to achieve this behavior is to make the
configuration file a conffile. [...] This implies that the default
version will be part of the package distribution, and must not be
modified by the maintainer scripts during installation (or at any
other time)."
Note that once a package ships a modified version of that conffile,
dpkg will prompt the user for an action how to handle the upgrade of
this modified conffile (that was not modified by the user).
Further in 10.7.3: "[...] must not ask unnecessary questions
(particularly during upgrades) [...]"
If a configuration file is customized by a maintainer script after
having asked some debconf questions, it may not be marked as a
conffile. Instead a template could be installed in /usr/share and used
by the postinst script to fill in the custom values and create (or
update) the configuration file (preserving any user modifications!).
This file must be removed during postrm purge.
ucf(1) may help with these tasks.
See also https://wiki.debian.org/DpkgConffileHandling
In https://lists.debian.org/debian-devel/2012/09/msg00412.html and
followups it has been agreed that these bugs are to be filed with
severity serious.
debsums reports modification of the following files,
from the attached log (scroll to the bottom...):
2m49.1s ERROR: FAIL: debsums reports modifications inside the chroot:
/etc/pam.d/sshd
cheers,
Andreas
fusionforge-shell_6.0.1-1.log.gz
Description: application/gzip
--- End Message ---
--- Begin Message ---
Hi,
2 points:
- FusionForge has been doing this for more than a decade, without any
user raising any issue. This is a good indicator that we are doing
things right.
- FusionForge, with its past history as a Debian-hosted GForge
semi-fork, is one of the only properly packaged Forges. Other
forges made hasty local .debs or deployed through custom means.
Also one of the key point of FusionForge is it's a backbone for
other components such as Git or Mailman, which is rare since other
projects like to reinvent the wheel.
This IMHO explains why other 20K+ packages usually don't have this
issue.
I see 2 ways to work-around this:
- Reassign the bugs to 'policy', so it clearly takes this case into
account (for the record, I don't really share anbe's interpretation)
- Deregister all the post-install scripts and tell the user to run
them manually (which will breaks current manual and Puppet
deployments since it normally works with a single 'apt-get').
I'm closing these bugs. Readers, feel free to reopen them with a bug
report from an actual user, or an improvement that would both match
our users' expectations and the QA's.
Best regards,
Sylvain
On Sat, Jul 04, 2015 at 01:38:43PM +0200, Holger Levsen wrote:
> Hi Sylvain,
>
> as well explained by Andreas in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789772#15 these are serious
> bugs in your packages. They are serious because the violate the standards we
> as a distribution expect from our packages in stable - not because piuparts
> says so. (And that we as a dsitribution except quality packages is enforced
> by
> the release team.)
>
> Just claiming "there is no problem" is not an acceptable solution, not for
> our
> users (and neither for the release team). Users rightfully expect not to be
> prompted for such changes on upgrades, yet this can+will happen, as Andreas
> explained.
>
> As a sidenote, it's usually a good indicator thta one is doing something
> wrong, if 20000 other (source) packages don't show this behaviour / achieve
> it
> through other means... sometimes there are valid exceptions, but usually not.
--- End Message ---
