[pacman-dev] pacman-contrib package

[Xavier]

Allan McRae wrote:
> Hi everyone,
> 
> With the release of pacman 3.1.2 I was reminded to get around to putting 
> a pacman-contrib package into AUR/community like I said I would [1].  I 
> have categorized the files in the contrib directory below.
> 
> Utilities:
>   pacdiff
>   pacsearch

These two seems interesting to include indeed.

>   re-pacman (needs some updates? [2])

Well, I already didn't like this script in the first place, I found the 
idea ugly.
I still had a look at it to check if it worked. And I see the 
implementation is ugly as well, since it's based on -Qi output.
If you take a few steps back, what's happening is so stupid (I'm not 
blaming any one here, or maybe only me for not being able to provide 
patches) :
makepkg creates the .PKGINFO files
repo-add transform the .PKGINFO to desc/depends
pacman -Si/-Qi interprets the desc/depends file and display the info
re-pacman looks at -Qi output and try to translate it back to .PKGINFO
...

Just one example, the build date is stored as unix epoch, but pacman 
displays it in human readable way.
However, we are lucky here, since date is apparently able to convert it 
back :
39 >-builddate=$(pacinfo ${1} 'Build Date') 

40 >-echo "builddate = $(date -d "$builddate" +%s)"

The build date could be the date of today though.

Now if we try do to the same for size field, it will get uglier. But 
here again, we could compute the current size taken, which might have 
changed.

Empty fields in pacman -Qi output should be dealt with too (for example 
Groups = None).

Anyway, if you want an accurate re-pacman, you need to check the 
.PKGINFO creation in makepkg, and find out how to get that back from 
pacman -Q output.
Or change re-pacman to use directly the files in /var/lib/pacman/local/
And maybe before that, change the local database to use .PKGINFO format, 
to ease up re-pacman task :)

I have no interest in updating re-pacman though, because I don't use it 
and find it useless (even though I recognize it might be handy and 
practical in some cases, I still don't like it).

>   wget-xdelta.sh
>

We don't need this anymore in the git repo, do we?


> vim:
>   PKGBUILD.vim

That looks interesting for detecting some stupid errors / typos in 
PKGBUILDs. The colors are still nearly the same as in sh, except that it 
highlights the errors it finds in PKGBUILD fields.

>   vimproject (needs updated - developer use only)
> 

Indeed, this is only useful when you already have the whole source, so 
no need to package it.