Justin B Rye wrote: > Justin B Rye wrote: >> [...] It seems to me we should put all our coverage of >> redundant packages in 4.4.3 (mentioning "apt-get autoremove" and >> avoiding the word "obsolete"), put all our coverage of relic packages >> in 4.9, and leave the two sections completely unconnected. > > Here's an attempt at a patch to do that.
I haven't tried to format it, but it certainly has more of a chance of being well-formed than the patch I sent before. ;-) So for what it's worth, this gets my ack. [...] > Is it still true that deborphan is "highly recommended", or is that a > leftover from the days when it was the only tool that implemented any > of this functionality? I wouldn't mind a change that stops recommending deborphan. > And does popcon-largest-unused still work? It thinks I don't use my > web browser or window manager. Is it trying to find unused packages > by looking at the file access datestamps on a /usr file system that's > mounted noatime? Yup, and even relatime (now the default) will cause > trouble - see #298760. I think it should work with relatime, since that just ratelimits atime updates to once per day (unless mtime or ctime < atime). The "mount" manpage is seriously misleading. (Reference: linux/fs/inode.c::relatime_need_update()) [...] > Except that once I've collected under one bulletpoint all the ways of > finding removal candidates on the basis of redundant ex-dependencies, > it becomes obvious that popcon-largest-unused doesn't fit there; it > fits with all the other suggestions for finding removal candidates on > the basis of size, which are currently split between several > bulletpoints. So I've consolidated all of those, too. Looks good. Thanks much. Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org