On Fri, Sep 04, 2009 at 10:15:54AM +0200, Erich Minderlein wrote: > Hi Marcin > > I looked into the description of localepurge . > It is a simple bashscript, > > It looks if the string LC_MESSAGES appears at the end of the relevant > directory structure, > Then it looks down into that directory and others in the same depth and > deletes their contents. > The directories remains. > > QUOTE > if [ -d $LOCALEDIR/$LOCALE/LC_MESSAGES ]; then > for file in "$LOCALEDIR/$LOCALE"/*/* > do > if [ -f "$file" ] || [ -h "$file" ]; then > /bin/rm "$file" > fi > done > fi > UNQUOTE > > that is the core of the function. > pretty simple.
Thanks for finding this out - great job! This means that we'll need a filter line such as: $LOCALEDIR/$LOCALE/*/* for every value of $LOCALE such that $LOCALEDIR/$LOCALE/LC_MESSAGES exists and is a directory. Such filter file should probably be generated at runtime, because: 1) the check for $LOCALEDIR/$LOCALE/LC_MESSAGES also happens at runtime. 2) locales to keep are determined at runtime based on a config file That would not be 100% accurate, given that: - .../*/* would match everything, not just files and symlinks. However it's hard to know for sure what it was after it was already deleted, without modifying localepurge to log such information. - if $LOCALEDIR/$LOCALE/LC_MESSAGES is not provided by a package which does OTOH provide $LOCALEDIR/$LOCALE/LC_FOO/bar, then deleting all packages providing files in $LOCALEDIR/$LOCALE/LC_MESSAGES would suddenly again cause "missing" messages about $LOCALEDIR/$LOCALE/LC_FOO/bar This actually makes me wonder if localepurge's author really wanted to check just for existence of LC_MESSAGES, while deleting contents of all subdirs. I've asked by creating Bug#546028. However being overzealous in the first case is not a big problem. For the second case (which I don't suppose would be very frequent), we can either skip the check for LC_MESSAGES (thus also filtering slightly too many warnings than we should) or document this as a case where sysadmin has to manually create the LC_MESSAGES directory. Let's see what the localepurge maintainer says. Now we need to find out the logic for determining which locales to skip, based on localepurge config file. I hope the config file has a simple syntax and no fancy features like variable expansion or wildcards? Now, going further, one might want to check that localepurge deletes all files, and have an _explain_ script for localepurge, that would list files provided by packages, that localepurge should have deleted (creating msnt_localepurge). As things are now, this would conflict with the must_dpkg file created by the dpkg explain script, simply causing a lot of warnings, rather than do the "right thing" :-( One way to work around this would be to have a configuration file which would allow to specify (possibly pair-wise) priorities of different explain scripts outputs. This could be used by merge_diff to determine what to do in a conflict situation: - warn about it or - silently ignore the lower-priority explain script decision But that part would be an even lower priority bug. > btw: the intent of the developper(s ) is that dpkg will only install the > the needed -permitted- locales, then localepurge will be obsolete. I believe this was the plan for literally years and years... I wouldn't hold my breath :-) As an aside, from a quick look at localepurge I can see that it also has code to delete manpages... > More useful ideas or other features: > > 1. when fresh installing debian|ubuntu|debianbased* there is a locale > setup policy - dpkg-reconfigure locales. this creates locales on the > system. However I do not see where the information is left behind. > This could be used to control localepurge instead of /etc/locale.nopurge > Then the system has no redundant information and stays in sync. > There could be a /etc/apt/apt.conf.d/99-cruft script, generating a new > explain file. (or as a cron job) I think an explanation might be that localepurge pre-dates dynamic libc6 locale data generation (i.e. dpkg-reconfigure locales), though I'm not sure. Maybe it's worth suggesting this to the localepurge maintainer? > 2. after studying man cruft again, > is there a feature to limit the depth in directory levels of the > report ? when scanning / , I might just want to know if the root > directory is clean ? > it could be a useful addition. > cruft -D 1 -m root / > cruft --depth=1 --mail root / No, there is no such option. Could you please file a separate wishlist bug for this? > 3. for /home/$USR/.* and /root/.* I could imagine it could be useful to > check hidden directories and files for the justification of their > existence by comparing with the installed applications. > They might stem from old temporary installed versions or from an > everlasting migration, such as mine. > I migrated $HOME from SuSE 4.3 to SuSE 7.3 and then on to > debian sarge, etch, ubuntu FF to ubuntu HH. > This happens now over 12 years and over 5 hardwares. I am not the only > one. Yes, this is a pain for me too. This is also a good idea, can you file it separately as well? > bash is very powerful and I do not have a knowledge, what are the usual > coding conventions, i.e. what is preferred in the devs community . > are there conventions or templates or rules for init.d scripts ? I don't know of any "bash style guide" I'm afraid.. regards, -- Marcin Owsiany <[email protected]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 "Every program in development at MIT expands until it can read mail." -- Unknown -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
