[pacman-dev] pacman-disowned

Allan McRae allan at archlinux.org
Wed Oct 2 22:38:55 EDT 2013


On 02/10/13 10:55, Jeremy Heiner wrote:
> First, the /home question...
> 
> Everything under an unmanaged dir is guaranteed(*) also to be
> unmanaged. So only the immediate contents of /home would be listed.
> That's actually one of the mistakes the shell script makes: it runs
> find, so it could potentially waste a lot of time digging deep into
> the filesystem. My scala prototype only ever examines the contents of
> managed dirs. That is all that's needed to answer the question "where
> is all the unmanaged stuff on my filesystem?".
> 
> (*) Actually the approach works even if this is relaxed (i.e. managed
> items within unmanaged dirs). My prototype examine all dirs containing
> managed items and all parents of all such dirs - still way fewer than
> find would.
> 
> My thoughts on the output are still nebulous. But I'm envisioning
> something like `ls -l`...
> 
> The "-rwx" part would indicate status. The first letter could be 'p'
> (or '-') to indicate managed (or not). Next maybe 'f' (or '-') if it
> exists in the filesystem (or not), and an 'm' if there is an mtree
> signature. Then one letter for each of the mtree tests: Uid, Gid,
> Mode, Time, Kind, Link, Size, ... where the capital letter indicates
> failure and '-' indicates success. I'm sure I'll remember more to add
> later.
> 
> The next column (like "size" for ls) could show the number of packages
> claiming ownership. My prototype actually lists all the owners instead
> of just counting, but that's maybe a "-verbose" option. I include the
> count because a 1 here is boring so you want a way to filter those
> entries out.
> 
> Add the item name at the end and you get:
> 
> pf-------- 94 /etc/
> pfm-------  1 /etc/arch-release
> -f--------  0 /etc/crackdict
> pfm---T---  1 /etc/crypttab
> -f--------  0 /etc/group-
> p---------  1 /etc/motd
> 
> Something along those lines. The unit tests for -Qk and -Qkk are
> almost ready to go, but real life stuff keeps interrupting...
> tomorrow, I hope.

I am very against that style of output.   I want it to be clear what the
change is without having to decipher a code.

Allan



More information about the pacman-dev mailing list