On Friday 20 May 2005 09:42, Jonas Smedegaard wrote: > Package: desktop-profiles > Version: 1.4.5 > Severity: serious > Justification: Policy 10.7.4 > > The file /etc/gconf2/path is a conffile owned by the package gconf2.
That file is left alone by default on installation of desktop-profiles.
The (first-time) installation tells the user that:
1) gconf profiles won't work with the current default path file
2) tells the user that a default path file that will work is available
in /usr/share/doc/desktop-profiles/examples/path
3) asks the admin (with a default answer of _no_) if he wants to replace the
default path file to be replaced.
-> by default the package won't mess with any other packages conffiles
-> only if the _admin_ decides to change the default path file, this will be
done, i.e. it is a direct result of admin action.
=> AIUI this is ok, specifically policy 10.7.3 has the following:
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 otherwise
be good citizens.
key part here in this case is the "must not overwrite or otherwise mangle
the user's configuration _without_asking_"
desktop-profiles confirmes with that (no configuration changes will be done
without the admin of the box explicitly telling us to do so)
> Postinst of desktop-profiles offers through debconf to mess with that
> file. That is a violation of Debian Policy section 10.7.4.
as explained above I read policy 10.7.3 as allowing the offer (as long as it
defaults to no, which it does).
It just offers a convienence to the admin, _if_ he decides to change the
default path file, he can now do it by selecting yes, instead of having to
drop to a commandline and cp a file.
In either case it's still the _explicit_action_ of the admin that's
overwriting the default gconf path file, it's just the means by which he
does so that's different.
> I see no other policy-compliant approaches to fixing this than either
> a) Convince the gconf2 maintainer to adopt your hack
was planning on contacting the gconf2 maintainer already (I'll probably get
around to that this weekend), I don't expect that debconf-question to be a
long-lived thing.
> c) Provide your hack only as a "tweak"
that's the current situation I think, no?
> By "tweak" I mean write a self-contained script, include it with your
> package, and make a note to the local admin in README.Debian about its
> existence.
that's done, in addition when I tell the admin about the tweak* he has the
_option_ (again defaulting to no) to have the tweak activated now, when
this happens it's because the admin explicitly acted to have it happen.
* in a debconf note, and in the manpage, not the readme, but that's ok no?
--
Cheers, cobaco (aka Bart Cornelis)
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)
pgpgIM9At5usY.pgp
Description: PGP signature
