Xavier pointed out a few pending items to me with pacman, and I thought I'd respond to his list here on the ML. Thoughts welcome from anyone else.
* -Qo and symlink : http://www.archlinux.org/pipermail/pacman-dev/2008-February/011061.html http://shining.toofishes.net/gitweb/gitweb.cgi?p=pacman.git;a=commit;h=cd43c...
Merged into maint tonight.
* pacman.conf clean up : http://www.archlinux.org/pipermail/pacman-dev/2008-January/010996.html
Replied to this message on the ML.
* ChangeLog.proto : http://archlinux.org/pipermail/arch-dev-public/2008-January/004020.html http://shining.toofishes.net/gitweb/gitweb.cgi?p=pacman.git;a=commitdiff;h=6...
Merged.
* install contrib files http://www.archlinux.org/pipermail/pacman-dev/2008-January/010782.html
How about an AUR package? pacman-contrib? Someone might even maintain it in community.
* ignore targets not found : point 2) there : http://www.archlinux.org/pipermail/pacman-dev/2007-September/009412.html
3.2 issue for sure. Interesting, but I like programs to fail hard with invalid input rather than gloss it over. When you script programs, it can be very misleading if things don't fail when you expect them to.
* broken database with two duplicated entries : for example : var/lib/pacman/local/xorg-xauth-1.0.1-1/ var/lib/pacman/local/xorg-xauth-1.0.2-1/
If we want to do this check in testdb, don't we need db_splitname or something? If we do it in libalpm, where exactly?
I punted this one to Xavier because I didn't exactly know how to do it. :) Can't we just load the entire local pkgcache and then scan for duplicate names? I was originally thinking of doing this outside of libalpm, and at some point we can add some consistency checks into the library if necessary that ensure no pkgname is duplicated inside a single repo.
* segfault : FS#9235
* memleak caused by 8240da6cb3ff95ad480efe3e1876104024398fae how to track whether a package has been added to the pkgcache or not. The target list is currently never freed. only the pkgcache is. If a package from the target list hasn't been added to the cache (because of a failure, conflict or whatever), it won't be freed.
Xavier- if you could bring this up in a separate email thread, that would probably be best. This is an issue where people are just going to have to sit down and try and work out a system for being sure of when/where a package needs to be freed.
* -Ru (unneeded) branch http://shining.toofishes.net/gitweb/gitweb.cgi?p=pacman.git;a=shortlog;h=unn...
Mostly because I just haven't merged it yet. I'll try to get a good look at this soon and see if it is good to go for master.
* xdelta support maybe we need a mail about the status on this, what needs to be done: http://bbs.archlinux.org/viewtopic.php?id=43426 (waiting on Nathan)
xdelta support in repo-add would probably be our next step- we may need to refactor the common code out of repo-add and makepkg into some kind of makepkg lib, which I am not completely sure how to address.
* upgrade refactoring status mail on this too?
What does this refer to? The idea of our add/remove package lists? If so, it is still an idea brewing in a lot of our heads but no one has made any huge advances on it yet. Of course, it is not going to me an easy or clean change either. -Dan