On Tue, May 08, 2012 at 11:58:12PM +0200, Andreas Beckmann wrote: > > during a test with piuparts I noticed your package left unowned files on > the system after purge, which is a violation of policy 6.8 (or 10.8): > > 0m26.6s ERROR: FAIL: Package purging left files on system: > /etc/console-setup/ owned by: console-setup-linux > /etc/console-setup/ISO-8859-15.acm.gz not owned > /etc/console-setup/Lat15-Fixed16.psf.gz not owned > /etc/console-setup/cached_ISO-8859-15_del.kmap.gz not owned
I don't know how I can fix this. There is no way to tell whether a file in /etc/console-setup has been created by console-setup or it is some unrelated font or keyboard file put there by the admin. (The file names are not entirely predictable.) What about about a README inside /etc/console-setup to warn the admin that any font or keyboard file in this directory may be removed when console-setup or console-setup-mini are purged? Notice that the files left in /etc/console-setup are not configuration files. They are put there because console-setup uses the directory /etc/console-setup as if it were /var/lib/console-setup. The problem is that console-setup needs access to a directory similar to /var at time when /var is not yet mounted. BTW, this is also a policy violation with no solution at the moment. If console-setup used a directory in /var then it would be more or less safe to remove it. Now, when it is in /etc there could be some files put there by the admin and we are not permitted to remove such files. There is another problem related to this bug report. Consider the following scenario: 1. The sistem uses console-setup 2. console-setup is removed (not purged) 3. console-setup-mini is installed Now console-setup-mini uses the files in /etc/console-setup put there by console-setup. 4. console-setup is purged (and the files currently used by console-setup-mini are removed). This problem is not serious because both console-setup and console-setup-mini are able to automatically recreate any removed files in /etc/console-setup (theoretically problems could arise only during the first reboot if fsck failed at time when /usr was not yet mounted). Anton Zinoviev -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
