Re: Application files in $HOME
On Mon, Jun 30, 2003 at 10:57:40PM +0200, Matthias Urlichs wrote: Hi, Mathieu Roy wrote: Gimp and many others software creates dotfiles. Because from the start you configure it (cache size, temp dir). Why should I want a per-user configuration option for temp file location? For their size? Apart from web browser cache, what can be so big? So? Browser caches should be deleted too, when the browser is deinstalled. What if I want to keep the history, bookmarks, or whatever perhaps even for an enhanced version (think Mozilla, Galeon, Epiphany and all of that). Anyway, there's email readers (my .sylpheed is 73 MBytes), news readers, picture browsers, ... my ~/.sylpheed is bigger than my ~/.kde. 73 Mbytes? What does sylpheed save in its directory? Sent mail, perhaps? If so, I personally would be *very* pissed off if uninstalling the package would delete all my sent mail (even if it were a custom binary format). Now, if one removes or purges, say, KDE to install an unofficial version... would (s)he loose all his icons and configuration? It would be nice, perhaps, having a tool to do it by hand, but I don't think everybody wants it to be done automatically when removing packages. Well designed software that change their configuration file should be able to handle an older configuration file. That's not the point. The point is that a program will never be able to change the default for any option from FOO to BAR, because FOO is hardcoded in every user's configuration file -- and it can't know whether the user has FOO in there because they explicitly set it, or because it's the default. Yes, but I don't think it's worth the effort (and the risk of pissing off lots of people). Why not simply put a note in README.Debian, if it's that important? Regards, -- Esteban Manchado Velázquez zoso*demiurgo*org - http://www.demiurgo.org No software patents in Europe! - eurolinux.org - proinnova.hispalinux.es Join Amnesty International - http://www.amnesty.org/actnow pgp9e7e0tKLLT.pgp Description: PGP signature
Re: Application files in $HOME
On Tue, Jul 01, 2003 at 12:49:10PM +0100, Esteban Manchado Vel?zquez wrote: On Mon, Jun 30, 2003 at 10:57:40PM +0200, Matthias Urlichs wrote: Anyway, there's email readers (my .sylpheed is 73 MBytes), news readers, picture browsers, ... my ~/.sylpheed is bigger than my ~/.kde. 73 Mbytes? What does sylpheed save in its directory? Sent mail, perhaps? If so, I personally would be *very* pissed off if uninstalling the package would delete all my sent mail (even if it were a custom binary format). Now, if one removes or purges, say, KDE to install an unofficial version... would (s)he loose all his icons and configuration? It would be nice, perhaps, having a tool to do it by hand, but I don't think everybody wants it to be done automatically when removing packages. Indeed, it's definitely an incredibly bad idea to try to remove things in users' home directories by hand. Consider people who keep their home directories in sync (whether it be version control, NFS, unison, or whatever) across multiple systems. Those people definitely don't want purging a package on just one system to mess about with their shared home directory. -- Colin Watson [EMAIL PROTECTED]
Re: Application files in $HOME (reformulated proposal)
Em Ter, 2003-07-01 às 08:49, Esteban Manchado Velázquez escreveu: It would be nice, perhaps, having a tool to do it by hand, but I don't think everybody wants it to be done automatically when removing packages. Well, this is the beggining of the proposal, that is: Include into debian package another control file that says which files it creates in the user's home, so that can be made a simple program that the user runs and see: icewm created this files, and, as I don't use icewm anymore, I don't need them. P.S.: This thread went to another point when people said just do ls -ld .*. My proposal was made thinking Debian as a desktop-user-friendly operating system. (Maybe I should discuss with debian desktop project before asking here). Em Ter, 2003-07-01 às 08:49, Esteban Manchado Velázquez escreveu: On Mon, Jun 30, 2003 at 10:57:40PM +0200, Matthias Urlichs wrote: Hi, Mathieu Roy wrote: Gimp and many others software creates dotfiles. Because from the start you configure it (cache size, temp dir). Why should I want a per-user configuration option for temp file location? For their size? Apart from web browser cache, what can be so big? So? Browser caches should be deleted too, when the browser is deinstalled. What if I want to keep the history, bookmarks, or whatever perhaps even for an enhanced version (think Mozilla, Galeon, Epiphany and all of that)
Re: Application files in $HOME
On Tuesday, Jul 1, 2003, at 07:49 US/Eastern, Esteban Manchado Velázquez wrote: 73 Mbytes? What does sylpheed save in its directory? Sent mail, perhaps? Not sure about sylpheed, but my evolution directory is even bigger. It's all cached IMAP mail. Hmmm, on this Mac, I've got 600MB of cached offline mail in nearly 23,000 files (Apple's Mail.app, not evolution). You'd think alt.binaries.pictures.* lived in my mailbox...
Re: Application files in $HOME
On Wed, 2 Jul 2003, Colin Watson wrote: On Tue, Jul 01, 2003 at 12:49:10PM +0100, Esteban Manchado Vel?zquez wrote: On Mon, Jun 30, 2003 at 10:57:40PM +0200, Matthias Urlichs wrote: Now, if one removes or purges, say, KDE to install an unofficial version... would (s)he loose all his icons and configuration? It would be nice, perhaps, having a tool to do it by hand, but I don't think everybody wants it to be done automatically when removing packages. Indeed, it's definitely an incredibly bad idea to try to remove things in users' home directories by hand. Consider people who keep their home directories in sync (whether it be version control, NFS, unison, or whatever) across multiple systems. Those people definitely don't want purging a package on just one system to mess about with their shared home directory. No one expects the sysadmin to remove their own files... in fact, people do believe their home directories are private, and are going to (rightfully) see the sysadmin even _reading_ them as an invasion of privacy. Backing up or moving the entire dir to another physical disk during an upgrade is ok, as long as the admin doesn't meddle with the contents of the dir. How I understand Daniel Ruoso's idea, is making: 1. a repository for keeping track of the names used for their $HOME/ files by packages that had been installed somewhen in the system's history. Example: wmaker: (GNUstep/) joe:(.joerc,.jstarrc,.editorrc,.jmacsrc,.jpicorc, .rjoerc) mc: (.cedit/,.mc/) links: (./links) This repository could optionally hold some information whether the file in question is installed by that package by default or has to be copied by the user. If the former applies, it might even give some way to tell if that config is likely to have been modified by the user or not. 2. a browser which, when invoked by the user, produces a nice list similar to: File SizePackageStatus GNUstep/ 150MB wmaker purged .jstarrc 2KB joeinstalled .cedit/ 40KBmc removed .mc/ 6KB mc removed (the original idea involved listing just purged packages, but an user over the quota (no one else ever takes any time to clean up their dirs :p) is pretty likely to consider getting rid of unneeded dotfiles even if the package in question is still installed). The user would then be able to either mark the files for removal is some nifty ncurses-based browser akin to dselect, or type something like userconfpurge delete --status=purged. Whipping up some nice browser and it's command-line backend is not a problem. Making the repository is. Regards, 1KB /---\ Shh, be vewy, vewy quiet, | [EMAIL PROTECTED] | I'm hunting wuntime ewwows! \---/ Segmentation fault (core dumped)
Re: Application files in $HOME
Hi, Mathieu Roy wrote:
Gimp and many others software creates dotfiles. Because from the start
you configure it (cache size, temp dir).
Why should I want a per-user configuration option for temp file location?
For their size? Apart from web browser cache, what can be so big?
So? Browser caches should be deleted too, when the browser is deinstalled.
Anyway, there's email readers (my .sylpheed is 73 MBytes), news readers,
picture browsers, ... my ~/.sylpheed is bigger than my ~/.kde.
Well designed software that change their configuration file should be
able to handle an older configuration file.
That's not the point. The point is that a program will never be able to
change the default for any option from FOO to BAR, because FOO is
hardcoded in every user's configuration file -- and it can't know whether
the user has FOO in there because they explicitly set it, or because it's
the default.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
Nirvana? That's the place where the powers that be and their friends hang out.
-- Zonker Harris
Re: Application files in $HOME
Richard Braakman [EMAIL PROTECTED] a tapoté : I have a better idea :) What if packages don't leave droppings in my home directory in the first place? I have all sorts of dotfiles (and even dot-directories) that I never asked for. It's reasonable for a program to install a dotfile when I configure it differently from the default, but there's no reason to create a dotfile that's identical to the default. Example? Gimp and many others software creates dotfiles. Because from the start you configure it (cache size, temp dir). In addition to being annoying in themselves, How? For their size? Apart from web browser cache, what can be so big? such useless dotfiles get in the way when a newer version has different defaults or incompatible configuration fields. Well designed software that change their configuration file should be able to handle an older configuration file. When I do configure a program (if it doesn't have an interactive configuration interface), I want to do it by creating a small, human-editable file that contains the _differences_ from the defaults. So even then I have no use for a copy of the default configuration. (If I want an example, I can look in /usr/doc/$foo/examples, which is a better place for it than $HOME.) You want to make your copy from a file in /usr/doc/$foo/examples. I'm not sure that what most users want to do. I'm pretty sure that people using kmail are happy to have a GUI to configure their mail account, for instance. -- Mathieu Roy Homepage: http://yeupou.coleumes.org Not a native english speaker: http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english
Re: Application files in $HOME
Richard Braakman [EMAIL PROTECTED] writes: On Wed, Jun 25, 2003 at 02:02:04PM -0300, Daniel Ruoso wrote: What if the packages tells to dpkg which files or directories it will create on the user's home directory and when a package is purged the user could run a program to purge the files of packages that no longer exists. I have a better idea :) What if packages don't leave droppings in my home directory in the first place? I have all sorts of dotfiles (and even dot-directories) that I never asked for. It's reasonable for a program to install a dotfile when I configure it differently from the default, but there's no reason to create a dotfile that's identical to the default. Amen, brother! $ ls -Ad ~/.* | wc -l 241 -- Poems... always a sign of pretentious inner turmoil. pgpoTAP7pod8x.pgp Description: PGP signature
Re: Application files in $HOME
Well, it may be included in the wishlist for cruft, the program I called userconfpurge may be a part of it. But before this would be necessary a change in the debian packages, to include which files are created in the user's home. Em Qui, 2003-06-26 às 14:31, Drew Scott Daniels escreveu: Is connecting files to packages like this part of cruft? A potential wishlist item for cruft? Drew Daniels -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Application files in $HOME
Em Sex, 2003-06-27 às 02:14, Adam Majer escreveu: Then they should't delete anything with .* After all, shoudn't most user friendly applications hide those directories in the first place? Even ls does it unless you use -a But the question is: These files and directories uses a lot of disk space... And today we have to clean another user's home, because there is no way to a newbie to clean it, because that demands a certain knowledge of the operating system and the packages that are installed. P.S.: think of an office with diskless stations running debian with the home over nfs and the authentication over nis, in this way we have to set a low quota, because we don't have much space in the hd. Furthermore, this is what a system admin is for. If something is broken, they can fix it remotely. I don't expect that a system admin even touch my home directory. And anyway, this doesn't need to be made in one day, think about debconf, there are packages that still doesn't use it and nobody died. I think that the two things are very different. debconf is not used by the end user. I was not talking about this. I was talking about the risk of this proposal. On the other hand, if someone is using Debian as a desktop and doesn't know how to upgrade it (and probably doesn't want to upgrade it too often) they will never run into the problem of run-away dot-files/dirs. Unless the user needs to keep its disk space below the quota.
Re: Application files in $HOME
On Wed, Jun 25, 2003 at 02:02:04PM -0300, Daniel Ruoso wrote: Hi, Recently I had a problem of exceeded quota in my home directory, so I went cleaning it, and I saw many and many files and directories with configurations for applications that I've runned in the past, but that packages were purged from my system a long time ago, so what is the idea (that can be a proposal)? What if the packages tells to dpkg which files or directories it will create on the user's home directory and when a package is purged the user could run a program to purge the files of packages that no longer exists. This will also help to know what these files means after all, I thought about a browser to inspect application's files in my home, so it will be easier to decide which files I don't want anymore... What is needed? The packages should have a control file (like conffiles) that tells which files this package will create. A repository to store this information so the user can browse it. A userconfpurge program that the user runs to remove purged packages configuration files A browser to associate the files with the packages and manage them (so the user can tell: I don't use icewm anymore, please remove it's configuration files). Is there risk involved? I don't know if different packages create conf files with the same name, if it does so, it would be necessary to avoid this practice. This would require a lot of work on the part of each maintainer to see which files get created where. One would need to change the Policy as well to require maintainers to actually use such a registry. I say it is not worth it. Just do a `ls -la` and delete the really old stuff that you know you don't need. Or even better, add yourself as a new user to the system, copy all the stuff you need from the old account, and when ready, remove the old account with all the directiries :) - Adam
Re: Application files in $HOME
Yes, I did it, but I'm not talking about me. I'm talking about a newbie user who doesn't understand why these files are in his home directory. This happens in the company I work... the administrative office works in debian and this people doesn't even know what is ls. Imagine if they can understand which files could be deleted whitout destroying the entire department. And anyway, this doesn't need to be made in one day, think about debconf, there are packages that still doesn't use it and nobody died. Em Qui, 2003-06-26 às 04:12, Adam Majer escreveu: On Wed, Jun 25, 2003 at 02:02:04PM -0300, Daniel Ruoso wrote: Hi, Recently I had a problem of exceeded quota in my home directory, so I went cleaning it, and I saw many and many files and directories with configurations for applications that I've runned in the past, but that packages were purged from my system a long time ago, so what is the idea (that can be a proposal)? What if the packages tells to dpkg which files or directories it will create on the user's home directory and when a package is purged the user could run a program to purge the files of packages that no longer exists. This will also help to know what these files means after all, I thought about a browser to inspect application's files in my home, so it will be easier to decide which files I don't want anymore... What is needed? The packages should have a control file (like conffiles) that tells which files this package will create. A repository to store this information so the user can browse it. A userconfpurge program that the user runs to remove purged packages configuration files A browser to associate the files with the packages and manage them (so the user can tell: I don't use icewm anymore, please remove it's configuration files). Is there risk involved? I don't know if different packages create conf files with the same name, if it does so, it would be necessary to avoid this practice. This would require a lot of work on the part of each maintainer to see which files get created where. One would need to change the Policy as well to require maintainers to actually use such a registry. I say it is not worth it. Just do a `ls -la` and delete the really old stuff that you know you don't need. Or even better, add yourself as a new user to the system, copy all the stuff you need from the old account, and when ready, remove the old account with all the directiries :) - Adam
Re: Application files in $HOME
Is connecting files to packages like this part of cruft? A potential wishlist item for cruft? Drew Daniels
Re: Application files in $HOME
On Wed, Jun 25, 2003 at 02:02:04PM -0300, Daniel Ruoso wrote: What if the packages tells to dpkg which files or directories it will create on the user's home directory and when a package is purged the user could run a program to purge the files of packages that no longer exists. I have a better idea :) What if packages don't leave droppings in my home directory in the first place? I have all sorts of dotfiles (and even dot-directories) that I never asked for. It's reasonable for a program to install a dotfile when I configure it differently from the default, but there's no reason to create a dotfile that's identical to the default. In addition to being annoying in themselves, such useless dotfiles get in the way when a newer version has different defaults or incompatible configuration fields. When I do configure a program (if it doesn't have an interactive configuration interface), I want to do it by creating a small, human-editable file that contains the _differences_ from the defaults. So even then I have no use for a copy of the default configuration. (If I want an example, I can look in /usr/doc/$foo/examples, which is a better place for it than $HOME.) Richard Braakman
