Re: What should postrm purge actually do?
On Tue, 3 Jun 2008 21:05:30 +0200 Michael Koch [EMAIL PROTECTED] wrote: So a good installer knows when you mount your $HOME on multiple machines and use some config files only on some machines? /irony Its the job of the user to cleanup his home. He knows best what he still needs. Or at least should know. When you have a lot of software installed on your system, it might get difficult to trace exactly which configuration files you need and which ones you don't need. Now imagine the following situation: a package's maintainer can declare the per-user configuration/cache files used by the program, so they are added to the dpkg database along with other files belonging to the package. It would then be trivial (or at least possible) to write a simple program which scans the user's home directory, and notifies the user of configuration/cache files which do not belong to any installed program. -- Andrea Bolognani [EMAIL PROTECTED] Resistance is futile, you will be garbage collected. pgpjr9jWpdgfG.pgp Description: PGP signature
Re: What should postrm purge actually do?
Andrea Bolognani [EMAIL PROTECTED] writes: Its the job of the user to cleanup his home. He knows best what he still needs. Or at least should know. When you have a lot of software installed on your system, it might get difficult to trace exactly which configuration files you need and which ones you don't need. Which is a good reason to use software that doesn't clutter your $HOME. Did you consider the case with $HOME being mounted on NFS with rootsquash (which is set by default)? Should the postinst then 'su' to each user to do the modifcations in that case then? How about if some extra security policy is active like apparmor or selinux? Sorry, the only sane option which is left is to keep maintainer scripts out of users home. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What should postrm purge actually do?
On Wed, 04 Jun 2008 12:16:40 +0200 Reinhard Tartler [EMAIL PROTECTED] wrote: When you have a lot of software installed on your system, it might get difficult to trace exactly which configuration files you need and which ones you don't need. Which is a good reason to use software that doesn't clutter your $HOME. Did you consider the case with $HOME being mounted on NFS with rootsquash (which is set by default)? Should the postinst then 'su' to each user to do the modifcations in that case then? How about if some extra security policy is active like apparmor or selinux? Sorry, the only sane option which is left is to keep maintainer scripts out of users home. Given your response, I see either you didn't read the whole message or I didn't explain myself clearly. I can try to re-elaborate if you need me to. -- Andrea Bolognani [EMAIL PROTECTED] Resistance is futile, you will be garbage collected. pgphFOA8YCehW.pgp Description: PGP signature
Re: What should postrm purge actually do?
Richard Kettlewell writes (What should postrm purge actually do?): Is it written down anywhere what postrm purge is supposed to do? Presumably remove some set of files, but what criteria should be used to choose which? Things I'm uncertain about, that someone might actually miss: - log files Yes, these should be removed. I think removing log files is a bad practice. A user may need to keep those log files (by law for example) and unbeknownst to them, debian has removed them when they removed web server X to replace it with web server Y. Log files should be out of bounds, even for --purge. Jeremiah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What should postrm purge actually do?
ke, 2008-06-04 kello 13:38 +0200, Jeremiah C. Foster kirjoitti: I think removing log files is a bad practice. A user may need to keep those log files (by law for example) and unbeknownst to them, debian has removed them when they removed web server X to replace it with web server Y. In that case they should not purge the packages. Note that package maintenance tools don't purge by default, just remove. There are also cases where _not_ removing log files can result in legal liability: for example, in some parts of the world, it is not permissible to store mail logs for more than some periods of time. (I think. I can't find a reference right now, though.) I don't think Debian Policy is where we should make sure all Debian systems obey all local laws. This is one case where, I think, we need to have sysadmins do that part themselves. Maintaining an operating system always requires some expertese and those maintaining Debian systems need to know the difference between remove and purge. Log files should be out of bounds, even for --purge. Doing that would mean log files never get cleaned up, unless the sysadmin realizes that they need to it manually. That's not a good situation, either. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What should postrm purge actually do?
Lars Wirzenius [EMAIL PROTECTED] writes: ke, 2008-06-04 kello 13:38 +0200, Jeremiah C. Foster kirjoitti: Log files should be out of bounds, even for --purge. Doing that would mean log files never get cleaned up, unless the sysadmin realizes that they need to it manually. That's not a good situation, either. When for example logrotate is used maybe that could keep rotating the file(s) till it is gone. So on purge the logfiles remains and then one disapears every day. Logfiles would be kept as long as with the software installed. You just don't get new ones. I think nobody could fault that method. Now how wants to write a patch for logrotate for this? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What should postrm purge actually do?
On Wed, Jun 04, 2008 at 01:38:30PM +0200, Jeremiah C. Foster wrote: Richard Kettlewell writes (What should postrm purge actually do?): Things I'm uncertain about, that someone might actually miss: - log files Yes, these should be removed. I think removing log files is a bad practice. A user may need to keep those log files (by law for example) and unbeknownst to them, debian has removed them when they removed web server X to replace it with web server Y. Log files should be out of bounds, even for --purge. Except, you EXPLICITELY asked for removing all cruft left by the package. If you want the junk left, that's what remove is for. And the Policy specifically names log files as something which should go away on purge but not on remove. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What should postrm purge actually do?
On Wed, Jun 04, 2008 at 02:20:08PM +0200, Goswin von Brederlow wrote: Lars Wirzenius [EMAIL PROTECTED] writes: ke, 2008-06-04 kello 13:38 +0200, Jeremiah C. Foster kirjoitti: Log files should be out of bounds, even for --purge. Doing that would mean log files never get cleaned up, unless the sysadmin realizes that they need to it manually. That's not a good situation, either. When for example logrotate is used maybe that could keep rotating the file(s) till it is gone. So on purge the logfiles remains and then one disapears every day. Logfiles would be kept as long as with the software installed. You just don't get new ones. How will it know that these logfiles are there? The config file for them is gone during the purge... People should just use remove if they care about their log files. Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What should postrm purge actually do?
Did you consider the case with $HOME being mounted on NFS with rootsquash (which is set by default)? Should the postinst then 'su' to each user to do the modifcations in that case then? How about if some extra security policy is active like apparmor or selinux? Sorry, the only sane option which is left is to keep maintainer scripts out of users home. Exactly, and on our network we mount all NFS shares rootsquashed to avoid stuff like this. Only root on the file server has access to users' directories. However, maintainer scripts should never mess with user's homes; the users may have the software installed locally, or the package may purged by mistake. Cheers, Morten -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What should postrm purge actually do?
Andrea Bolognani skrev: When you have a lot of software installed on your system, it might get difficult to trace exactly which configuration files you need and which ones you don't need. Now imagine the following situation: a package's maintainer can declare the per-user configuration/cache files used by the program, so they are added to the dpkg database along with other files belonging to the package. It would then be trivial (or at least possible) to write a simple program which scans the user's home directory, and notifies the user of configuration/cache files which do not belong to any installed program. I like this idea. No automatic deletion, but helps each user reduce clutter. I might even help implement it if you make a DEP or something... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What should postrm purge actually do?
On Tue, Jun 03, 2008 at 08:58:54PM +0200, Jeffrey Ratcliffe wrote: Fine. Although it always annoyed me that my $HOME filled up with spurious dotfiles whose origin I'm not necessarily sure of, and that a good installer could know to remove them if the package were purged. If you run a shared /home by NFS mount, how would your installer know if the package is still in use on a nother system using the same /home? Or is there a better solution? (I'm not sure it is gconf) Stuff in /home is not something to worry about. That's for the user and only the user to worry about. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What should postrm purge actually do?
Frank Lichtenheld [EMAIL PROTECTED] writes: On Wed, Jun 04, 2008 at 02:20:08PM +0200, Goswin von Brederlow wrote: Lars Wirzenius [EMAIL PROTECTED] writes: ke, 2008-06-04 kello 13:38 +0200, Jeremiah C. Foster kirjoitti: Log files should be out of bounds, even for --purge. Doing that would mean log files never get cleaned up, unless the sysadmin realizes that they need to it manually. That's not a good situation, either. When for example logrotate is used maybe that could keep rotating the file(s) till it is gone. So on purge the logfiles remains and then one disapears every day. Logfiles would be kept as long as with the software installed. You just don't get new ones. How will it know that these logfiles are there? The config file for them is gone during the purge... That would be the part to teach logrotate. One way would be to tell logrotate that the config is to be removed when it has no more files and leave it on purge. Logrotate should then rotate as long as there are files and then delete the config last. People should just use remove if they care about their log files. Gruesse, MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What should postrm purge actually do?
On Tue, 03 Jun 2008, Richard Kettlewell wrote: Things I'm uncertain about, but that wouldn't be missed: - infrastructural stuff (lockfiles, sockets, etc) Probably. If the stuff isn't running anymore. - files containing cached data Things I'm uncertain about, that someone might actually miss: - log files Certainly. Policy 10.8 even spells it out. - data accumulated from users -- weasel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What should postrm purge actually do?
2008/6/3 Peter Palfrader [EMAIL PROTECTED]: - data accumulated from users Should I be doing something like rm /home/*/.packagedotfile for user-specific dotfiles? I don't see this in the policy. Regards Jeff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What should postrm purge actually do?
On Tuesday 03 June 2008 08:41:20 pm Jeffrey Ratcliffe wrote: 2008/6/3 Peter Palfrader [EMAIL PROTECTED]: - data accumulated from users Should I be doing something like rm /home/*/.packagedotfile for user-specific dotfiles? for the love of flying spaghetti monster please no :) a purge should only remove files that were installed by the package or otherwise incidentally generated in FHS compliant locations. data created in users' home directories is definitely outside such a scope. i.e., if dpkg couldn't put files there, it shouldn't try to remove files from there. sean signature.asc Description: This is a digitally signed message part.
Re: What should postrm purge actually do?
2008/6/3 sean finney [EMAIL PROTECTED]: a purge should only remove files that were installed by the package or otherwise incidentally generated in FHS compliant locations. data created in users' home directories is definitely outside such a scope. i.e., if dpkg couldn't put files there, it shouldn't try to remove files from there. Fine. Although it always annoyed me that my $HOME filled up with spurious dotfiles whose origin I'm not necessarily sure of, and that a good installer could know to remove them if the package were purged. Or is there a better solution? (I'm not sure it is gconf) Regards Jeff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What should postrm purge actually do?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/03/08 13:58, Jeffrey Ratcliffe wrote: 2008/6/3 sean finney [EMAIL PROTECTED]: a purge should only remove files that were installed by the package or otherwise incidentally generated in FHS compliant locations. data created in users' home directories is definitely outside such a scope. i.e., if dpkg couldn't put files there, it shouldn't try to remove files from there. Fine. Although it always annoyed me that my $HOME filled up with spurious dotfiles whose origin I'm not necessarily sure of, and that a good installer could know to remove them if the package were purged. Or is there a better solution? (I'm not sure it is gconf) As a user, I'd be really peeved if postrm automagically deleted my $HOME files. An informational message saying that app(s) in this package created the file(s) $HOME/.xyzzy and gconf entries A, B C would be helpful, though. - -- Ron Johnson, Jr. Jefferson LA USA I must acknowledge, once and for all, that the purpose of diplomacy is to prolong a crisis., Mr. Spock -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIRZfDS9HxQb37XmcRApCzAKCTZPxi7mrrwstmdr3CvBSdirU0CgCeJ+jh ZYOAk1FNnd3nNtwwErGo+hI= =HQov -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What should postrm purge actually do?
Richard Kettlewell writes (What should postrm purge actually do?): Is it written down anywhere what postrm purge is supposed to do? Presumably remove some set of files, but what criteria should be used to choose which? It's a shame that this isn't more clearly documented. The policy document is not much help; s6.8 says when it is called, but not what it actually needs to do. I can't find more detail, though of course I may have missed it. Things I think it should remove: - generated configuration files Definitely. Things I'm uncertain about, but that wouldn't be missed: - infrastructural stuff (lockfiles, sockets, etc) - files containing cached data Absolutely, it should remove all of these. You should remove these on postrm remove, in fact, and not wait for purge. Things I'm uncertain about, that someone might actually miss: - log files Yes, these should be removed. I have an old version of the policy manual from before it was merged with the dpkg programmers' manual, and that says to remove logfiles on purge. - data accumulated from users Configuration files might be missed too, so obviously --purge isn't intended to be nondestructive, the question is how destructive is it supposed to be and to what extent is it responsible for tidying up. I think you are allowed to make a judgement call here. The usual thing to do would definitely be to remove _everything_, so as to put the system back almost to the state as if the package hadn't been installed. (There may be minor exceptions, such as leaving users in passwd to avoid uid reuse.) But I think for example database packages don't generally remove their actual database data when they're purged, because they think the data is likely to be exceptionally important to the admin. Something that's exceptionally important is both more desirable to keep, and also less of a problem if the admin needs to manually tidy it up. Personally I would lean on the side of deleting the disorder user-entered data on purge but I can see arguments on both sides. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What should postrm purge actually do?
On Tue, Jun 03, 2008 at 08:58:54PM +0200, Jeffrey Ratcliffe wrote: Fine. Although it always annoyed me that my $HOME filled up with spurious dotfiles whose origin I'm not necessarily sure of, and that a good installer could know to remove them if the package were purged. It's important to distinguish between system and user, and the administrator of a machine isn't always the sole user. If a package is purged from the system it can deal with all the files it installed or generated because they aren't needed anymore. User configuration however isn't tied to the system. The user may have imported the configuration from some other machine, or intend to use the configuration elsewhere. The usefulness of user configuration is therefore not tied to the installed state of the package on this system. Until we have multi user mind reading hardware tied into dpkg, the only right thing is to never remove a user's files. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What should postrm purge actually do?
Andreas Bombe wrote: [...] The user may have imported the configuration from some other machine, or intend to use the configuration elsewhere. The usefulness of user configuration is therefore not tied to the installed state of the package on this system. Particularly since the user may have compiled their own copy of the application and be running it from their home directory! -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ I have always wished for my computer to be as easy to use as my │ telephone; my wish has come true because I can no longer figure out │ how to use my telephone. --- Bjarne Stroustrup signature.asc Description: OpenPGP digital signature
Re: What should postrm purge actually do?
On Tue, Jun 03, 2008 at 08:58:54PM +0200, Jeffrey Ratcliffe wrote: 2008/6/3 sean finney [EMAIL PROTECTED]: a purge should only remove files that were installed by the package or otherwise incidentally generated in FHS compliant locations. data created in users' home directories is definitely outside such a scope. i.e., if dpkg couldn't put files there, it shouldn't try to remove files from there. Fine. Although it always annoyed me that my $HOME filled up with spurious dotfiles whose origin I'm not necessarily sure of, and that a good installer could know to remove them if the package were purged. Or is there a better solution? (I'm not sure it is gconf) So a good installer knows when you mount your $HOME on multiple machines and use some config files only on some machines? /irony Its the job of the user to cleanup his home. He knows best what he still needs. Or at least should know. Cheers, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
