Bug#309871: desktop-profiles: Messes with conffiles of other packages
On Saturday 28 May 2005 22:25, Jonas Smedegaard wrote: On 28-05-2005 21:45, cobaco (aka Bart Cornelis) wrote: I'm currently working on a conversion script (not part of maintainer-scripts), that'll migrate path approach to desktop-profiles You don't like my cfengine script? I wrote it specifically for you! it's not that I don't like it, but that I don't think a cfengine script is the right approach (sorry): - I don't think you can assume that all (gnome) users of desktop-profiles have cfengine installed - using it to generate the necessary changes is definately suboptimal - the cfengine script doesn't move over management of non-default configuration sources to desktop-profiles, which means if you have any such beasts, you'll either be juggling 2 ways of managing configuration sources, or have to generate the necessary metadata manually. The conversion script will generate the necesaary metadat automatically I am interested in what you are cooking - maybe I can help spot possible problems, or maybe I can even learn from it :-) sure, many eyes make all bugs shallow and all that :-) current state of the conversion script can be seen at http://svn.debian.org/wsvn/debian-edu/trunk/src/desktop-profiles/path2desktop-profiles-metadata -- 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) pgpcvGhk14Pp2.pgp Description: PGP signature
Bug#309871: desktop-profiles: Messes with conffiles of other packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29-05-2005 15:44, cobaco (aka Bart Cornelis) wrote: On Saturday 28 May 2005 22:25, Jonas Smedegaard wrote: On 28-05-2005 21:45, cobaco (aka Bart Cornelis) wrote: I'm currently working on a conversion script (not part of maintainer-scripts), that'll migrate path approach to desktop-profiles You don't like my cfengine script? I wrote it specifically for you! it's not that I don't like it, but that I don't think a cfengine script is the right approach (sorry): Don't be sorry. But be aware of what you sack... - I don't think you can assume that all (gnome) users of desktop-profiles have cfengine installed - using it to generate the necessary changes is definately suboptimal Sure you can. Add the following to the control file of your package: Recommends: cfengine - the cfengine script doesn't move over management of non-default configuration sources to desktop-profiles, which means if you have any such beasts, you'll either be juggling 2 ways of managing configuration sources, or have to generate the necessary metadata manually. The conversion script will generate the necesaary metadat automatically This sounds like something additional to the earlier conffile overwriting (the reason for this bugreport). Probably great... It sounds like you only deal with the current state of the alien conffile and moving to the state your package needs the alien conffile to be in). That's also what my cfengine script does currently). But what when perhaps gconf is upgraded to use a different config format? And what breaks when your package gets removed? current state of the conversion script can be seen at http://svn.debian.org/wsvn/debian-edu/trunk/src/desktop-profiles/path2desktop-profiles-metadata Looks ok... Consider making backup of files messed with. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nr: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCmhLXn7DbMsAkQLgRAtoVAJ9PTRoBzBjWxOQpN38fYHxfrE2RygCfcRks LmxEXbx4g5IB/YneobtH7yY= =YZgU -END PGP SIGNATURE-
Bug#309871: desktop-profiles: Messes with conffiles of other packages
On Sun, 22 May 2005, Jonas Smedegaard wrote: On 21-05-2005 00:45, cobaco (aka Bart Cornelis) wrote: my hack does nothing in itself, the gconf path file is not being changed behind the admin's back, or on the packages initiative. _The_admin_is_the_acting_party_ Please elaborate on Debian Policy section 10.7.4, paragraph 2: The maintainer scripts must not alter a `conffile' of _any_ package, including the one the scripts belong to. Also, the sarge rc policy outlines it in even more detail: http://release.debian.org/sarge_rc_policy.txt Packages must not modify their own or other packages conffiles programmatically. (The only correct way to modify a conffile is the user running an editor specifically; if anything more automated is required or useful, configuration files must _NOT_ be handled as conffiles) Since that .../path file is a conffile it should be pretty clear that even asking the admin and then doing it is not acceptable. -- PGP signed and encrypted | .''`. ** Debian GNU/Linux ** messages preferred.| : :' : The universal | `. `' Operating System http://www.palfrader.org/ | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309871: desktop-profiles: Messes with conffiles of other packages
I'm currently working on a conversion script (not part of maintainer-scripts), that'll migrate path approach to desktop-profiles I'm currently unsure about wether to provide a hook through which the admin can start that script from within the package installation or not. This bug seams to imply don't do that, it's *BAD*, I just don't see why that would be so (see below) On Saturday 28 May 2005 19:22, Peter Palfrader wrote: On Sun, 22 May 2005, Jonas Smedegaard wrote: Please elaborate on Debian Policy section 10.7.4, paragraph 2: The maintainer scripts must not alter a `conffile' of _any_ package, including the one the scripts belong to. Also, the sarge rc policy outlines it in even more detail: Since that .../path file is a conffile it should be pretty clear that even asking the admin and then doing it is not acceptable. I don't see it as the maintainer script modifying the path file, but as the admin doing so (with a tool provided by the maintainer script) Assuming the script I spoke of above: I don't see any fundamental difference between the admin running the conversion script on a second terminal or after the installation, and the admin starting the script through a hook in the installation: - in either case it's the conscious decision of the admin to start the conversion script. - it's just the means through which the admin starts the script that's different, the hook making it sligtly easier for the admin -- 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) pgp72y48fJMFA.pgp Description: PGP signature
Bug#309871: desktop-profiles: Messes with conffiles of other packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28-05-2005 21:45, cobaco (aka Bart Cornelis) wrote: I'm currently working on a conversion script (not part of maintainer-scripts), that'll migrate path approach to desktop-profiles You don't like my cfengine script? I wrote it specifically for you! I am interested in what you are cooking - maybe I can help spot possible problems, or maybe I can even learn from it :-) I'm currently unsure about wether to provide a hook through which the admin can start that script from within the package installation or not. This bug seams to imply don't do that, it's *BAD*, I just don't see why that would be so (see below) Correct: tying anything that messes with files of other packages to the maintainer scripts is a violation of Debian Policy. You may choose to disagree with Debian Policy, but personally I do not want to debate that within this bugreport. I suggest you take that more general discussion either at debian-devel or (if you believe it is urgent to override Policy) at debian-release. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nr: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCmNPXn7DbMsAkQLgRAjtNAJ9NK9ZJMxmsyAMIPNmrvFl5SR+LWACcCyRm TlRAkg0lRl17Zi6sfHUXk20= =0fQ1 -END PGP SIGNATURE-
Bug#309871: desktop-profiles: Messes with conffiles of other packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 21-05-2005 00:45, cobaco (aka Bart Cornelis) wrote: my hack does nothing in itself, the gconf path file is not being changed behind the admin's back, or on the packages initiative. _The_admin_is_the_acting_party_ Please elaborate on Debian Policy section 10.7.4, paragraph 2: The maintainer scripts must not alter a `conffile' of _any_ package, including the one the scripts belong to. the debconf question is just a convenient means for the admin to act (in the simple case where there are no local changes, and just replacing is ok) The debconf question is part of the maintainer scripts. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nr: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCkPzyn7DbMsAkQLgRAntXAKCIZJtEm0xDCT+kQXVqySexVgH4rQCgjxjf fiNSp7grDOnwVZt4zwVX6Q8= =nTWo -END PGP SIGNATURE-
Bug#309871: desktop-profiles: Messes with conffiles of other packages
On Friday 20 May 2005 12:28, Jonas Smedegaard wrote: On 20-05-2005 10:46, cobaco (aka Bart Cornelis) wrote: On Friday 20 May 2005 09:42, Jonas Smedegaard wrote: 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. just got around to composing that mail, see bug 310065 for followup -- 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) pgpqoVHgIWSyp.pgp Description: PGP signature
Bug#309871: desktop-profiles: Messes with conffiles of other packages
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. Postinst of desktop-profiles offers through debconf to mess with that file. That is a violation of Debian Policy section 10.7.4. I see no other policy-compliant approaches to fixing this than either a) Convince the gconf2 maintainer to adopt your hack b) Convince the gconf2 maintainer to provide a tool for hacking c) Provide your hack only as a tweak 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. CDDs can then choose to break Debian Policy and automate the use of your tweak, possibly asking first through debconf. - Jonas P.S. If defining a CDD as something completely within Debian (as discussed recently on the debian-custom mailinglist) then off course they also are not allowed to automate your gconf2 tweak. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-rc3-mm3+debianlogo+squashfs Locale: LANG=da_DK, LC_CTYPE=da_DK (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Versions of packages desktop-profiles depends on: ii debconf [debconf-2.0] 1.4.49 Debian configuration management sy -- debconf information: * desktop-profiles/replace-gconf-system-wide-path-file: false -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309871: desktop-profiles: Messes with conffiles of other packages
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) pgpIKIzJ8xeVx.pgp Description: PGP signature
Bug#309871: desktop-profiles: Messes with conffiles of other packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 20-05-2005 10:46, cobaco (aka Bart Cornelis) wrote: 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. Second part of section 10.7.4: The maintainer scripts must not alter a `conffile' of _any_ package, including the one the scripts belong to. = AIUI this is ok, specifically policy 10.7.3 has the following: Section 10.7.3 discusses conffiles within same package, not interaction between files between several packages. 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. The current behaviour is *not* policy.compliant, so is a non-living thing ;-) c) Provide your hack only as a tweak that's the current situation I think, no? No. Your hack replaces the file, ignoring any and all local changes. Also, your hack is tied to the packaging scripts, so is only invoked by running dpkg-reconfigure and interacting with debconf. A self-contained and (to my belief) idempotent tweeak is now provided here: http://cvs.alioth.debian.org/cgi-bin/cvsweb.cgi/tweaks/oldtweaks/oldtweaks/gconf/?cvsroot=tweaks I suggest including the above script below /usr/lib/desktop-profiles/bin and mention its existense in your README.Debian. README.Debian is the first place to look for Debian-specific info - not the manpage and not a debconf-note (which is by nature optional). I recommend *not* putting it below /usr/share/doc/desktop-profiles/examples as that is discouraged as a location relied upon by other packages and the local admin (forgot where but mentioned in Debian Policy somewhere). I also recommend *not* putting it below /usr/sbin as its use is too narrow to clutter the general sbin namespace. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nr: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCjbvKn7DbMsAkQLgRAsbbAJ9w4bH8fHJ0bC3CpxtD1N5voi7ddACcCfg6 zFCouhJd51ZRIDx2FKbJQSk= =iXyJ -END PGP SIGNATURE-
Bug#309871: desktop-profiles: Messes with conffiles of other packages
On Friday 20 May 2005 12:28, Jonas Smedegaard wrote: On 20-05-2005 10:46, cobaco (aka Bart Cornelis) wrote: On Friday 20 May 2005 09:42, Jonas Smedegaard wrote: c) Provide your hack only as a tweak that's the current situation I think, no? No. Your hack replaces the file, ignoring any and all local changes. my hack does nothing in itself, the gconf path file is not being changed behind the admin's back, or on the packages initiative. _The_admin_is_the_acting_party_ the debconf question is just a convenient means for the admin to act (in the simple case where there are no local changes, and just replacing is ok) As far as replacing the local changes, there normally shouldn't be any (as the sysadmin is supposed to define any of his sources into one of the following 2 path files (which don't exist, but will be looked for, by default) include /etc/gconf/2/local-mandatory.path include /etc/gconf/2/local-defaults.path There might still be changes off course but this should be rare (and I'd expect the admin of the box to not replace the file in that instance) Also desktop-profiles basically provides an alternative way to manage (amongst others) gconf configuration sources. If you choose to use it, I'd expect you to move managing of any extra sources you have over to the desktop-profiles also. - I guess this really needs a conversion script (definately doable, i'll have to look at that) - I should probably add something about this in the debconf note (if that stays) to make that clearer Also, your hack is tied to the packaging scripts, so is only invoked by running dpkg-reconfigure and interacting with debconf. I don't see how that's a problem in itself: - in order to use desktop-profiles to manage gconf configuration sources the default path file needs to be changed (simple fact) - The above is not done by default, but there is a means provided that the admin can use to do so (in the case that simply replacing the file is enough) - The above means has a hook in the installation through which the admin can start it (NOTE: starting that means is an action by the admin, not the package) - Exactly what the actual mechanism is, I don't see as being relevant, as long as it does what it needs (though obviously some mechanisms may be better then others, and that's open to discussion) You're interpretation of policy would imply that simply providing a hook with which the admin can change something during installation, or when running dpkg-reconfigure is against policy (and thus implicitly somehow bad), If that's the case it definately shouldn't be IMO, as invoking the hook is an admin action, which is allowed to change config files (or am I missing something, I don't see how this is fundamentally different from providing a cfengine script for the admin to run) A self-contained and (to my belief) idempotent tweeak is now provided here: http://cvs.alioth.debian.org/cgi-bin/cvsweb.cgi/tweaks/oldtweaks/oldtweak s/gconf/?cvsroot=tweaks I suggest including the above script below /usr/lib/desktop-profiles/bin hm, this tweak uses cfengine, I don't think you can assume in general that cfengine will be installed (for CDD's possibly, but otherwise?) also the include /var/cache/desktop-profiles/$(USER)_mandatory.path should _replace_ the 2 lines xml:readonly:/etc/gconf/gconf.xml.mandator include /etc/gconf/2/local-mandatory.path not be appended after them: Those 2 sources are known to desktop-profiles by default, and thus will be managed by it (they will be included twice if they're also included in the system wide path file, which doesn't hurt in itself, though it does make things more complicated as you then need to be aware of both mechanisms) idem with the include /var/cache/desktop-profiles/$(USER)_defaults.path line, that should replace the 2 lines include /etc/gconf/2/local-defaults.path xml:readonly:/etc/gconf/gconf.xml.defaults for the same reason and mention its existense in your README.Debian. README.Debian is the first place to look for Debian-specific info - not the manpage and not a debconf-note (which is by nature optional). ack, added note to readme I recommend *not* putting it below /usr/share/doc/desktop-profiles/examples as that is discouraged as a location relied upon by other packages and the local admin (forgot where but mentioned in Debian Policy somewhere). it isn't _relied_ on be anything, the admin is perfectly fine ignoring it altogether, and/or writing his own path file. In the latter case he should include the 2 directives include /var/cache/desktop-profiles/$(USER)_mandatory.path include /var/cache/desktop-profiles/$(USER)_defaults.path somewhere in the path file (respectively before and after the user sources for) in order to have the sources managed by desktop-profiles work as expected I also recommend *not* putting it below /usr/sbin
