I have the 'localepurge' package installed,
which after package installation or upgrade
routinely deletes all files related to locales
I don't use (man pages, translation files, etc.).

These files are reported as missing by cruft,
and there is quite a lot of them.

It would be great if cruft could be given a
command line switch that does not report locale-
specific files as missing, otherwise important
messages are easily lost amid the thousands of
lines of missing locales files.

Cheers
-Tim

Hi!

Please have a look at bug #222232.

I think that a good way of solving this problem is that if cruft could
filter a list of "missing" files through localepurge (executed with some
special command line option), and localepurge would filter from this
stream the names of files which it had deleted (or, for that matter,
which it would have deleted).

This way cruft could learn about which files were "legitimately" deleted
from the system by localepurge, and only pass to the user what
localepurge doesn't claim to have taken care of.

What do you think about this? Would it be possible to implement in
localepurge? This would be a decently generic way of dealing with such
problems from cruft's point of view. If it would not be possible, maybe
you have a different idea on how this could be solved?

regards

Marcin

Hi Marcin,

just a short note: unfortunately i lack the time to bother about such
enhancements. But i wouldn't mind applying a patch.

On the other hand: why should it be considered a problem if cruft reports
files as missing? And why should localepurge solve what cruft can't handle?
Disclaimer: i never ever used cruft.

                                        Thanks, P. *8^)

OK, thanks for letting me know. I will look closer at localepurge and
let you know what I come up with.
isn't, or what shouldn't be there, but is. That is, to help system
administrator keep his system nice and tidy. And, apparently, to help
detect bugs in packages, especially regarding their {pre,post}{inst,rm}.

Short answer: because cruft can't really handle anything on its own.
It's just glue between what different packages and the filesystems
"say".

Longer answer: cruft needs to get from somewhere its knowledge on what
should or shouldn't be present on the system. For example, dpkg's file
database "says" that some ".mo" file should be there. I am simply
looking for a flexible and consistent way for other packages (like
localepurge) to "say" that "I have deleted some file installed by dpkg,
and that's OK".

regards,

Marcin

Just a note, that since 0.9.6-0.18 the new support for "files that must
not exist" and more flexible filter files could make resolving this bug
easier.

Hi, i just fell over this problem:

to make things short :
cruft shall read  /etc/locale.nopurge
These are the legitimate man pages and locales contained herein

anything which does not fit into this is either superfluos or missing

mine looks like this :
 grep -v ^# /etc/locale.nopurge | grep -v ^$
MANDELETE
DONTBOTHERNEWLOCALE
SHOWFREEDSPACE
de
de_DE
de_DE@euro
de_DE.UTF-8
en
en_GB
en_GB.ISO-8859-15
en_GB.UTF-8
fr
fr_FR
fr_FR@euro
fr_FR.UTF-8


If I can be of more assistance (testing , docu, ...)
best regards

Erich Minderlein

[...]

The hard (for me) part is transforming this list of locales into a list
of file patterns that would match files that localepurge would
delete/has deleted.

Hi Erich,

Is this just a list of directories where locale-dependent files reside,
or actually a list of directories that localepurge will process?

If the latter, then what does it do? Delete everything below them? Or
just files directly below? Or non-directories below?

That's what I meant by saing "hard" - we need a set of patterns that
will match everything that localepurge would delete but nothing more.
Vcs-SVN: svn://svn.debian.org/cruft/trunk
Vcs-Browser: http://svn.debian.org/wsvn/cruft/trunk/

Hi Erich,

Sorry for the long delay in replying

To be honest it would be better to have something based on the actual
localepurge algorighm, not its effects on one particular system.

Cruft's matching "engine" does not support named classes. Or any classes
for that matter, IIRC.

I don't want to sound harsh, but that script would need some work. It
contains some naive (in the technical sense) parsing and does not quote
arguments to "cat", to begin with.

regards,

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.

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...

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?

No, there is no such option. Could you please file a separate wishlist
bug for this?

Yes, this is a pain for me too.

This is also a good idea, can you file it separately as well?

I don't know of any "bash style guide" I'm afraid..

regards,

control: tag -1 wontfix

"#619086 cruft: support dpkg path-exclude/path-include" has now been implemented.

As "#603587 localepurge: Please use dpkg --path-exclude / --path-include to implement the service"
has been implemented for a long time; please use this feature and then
your localepurge-generated dpkg settings will be automatically picked-up by cruft-ng.

https://sources.debian.net/src/localepurge/0.7.3.4/debian/README.dpkg-path/

Greets,

Alexandre