[pacman-dev] Remaining issues

Dan McGee dpmcgee at gmail.com
Fri Dec 21 12:12:50 EST 2007

On Dec 21, 2007 5:12 AM, Xavier <shiningxc at gmail.com> wrote:
> On Wed, Dec 19, 2007 at 11:53:24PM -0600, Dan McGee wrote:
> >
> > We are close to release, folks. Anything else outstanding that is critical?
> >
> Hm well, nothing critical, but I thought there were several things that
> needed to be taken care of before the release, and not much happened during
> these last two weeks (sorry, I didn't have much time).
> 1) not important, easy to fix:
> * -Ru patch from Nagy is ready for quite a while, and it doesn't change any
> existing behavior, it just adds a new feature (however, it adds a new message
> to be translated) -> my unneeded branch

I'll try to look at this the next few days, and plan accordingly.
Maybe this would be better in a 3.1.1 release?

> 2) more important, easy to fix:
> * testdb is broken
> I fixed this on my testdb branch, and also added conflicts checking. nothing
> intrusive.

I pulled the bugfix patch, and I'll consider the other stuff sometime as well.

> * one memleak from Nathan was apparently ignored :
> http://www.archlinux.org/pipermail/pacman-dev/2007-December/0104
> and also, a little and good patch for ignorepkg :
> http://www.archlinux.org/pipermail/pacman-dev/2007-December/0104
> both pushed to my working branch

Both pulled to my working branch now (your links got cut off too btw).

> 3) important, hard to fix:
> * the backup handling is in a poor situation :
> http://www.archlinux.org/pipermail/pacman-dev/2007-December/010439.html
> http://www.archlinux.org/pipermail/arch-dev-public/2007-December/003868.html
> (with 3.1 , reinstalling filesystem makes the .pacnew appear though)
> * another weird issue with directory symlinks
> http://www.archlinux.org/pipermail/pacman-dev/2007-December/010451.html
> these two areas are my favorites (read: this really pisses me off).

I know we have problems here, but as far as I can tell, we don't have
regressions. Correct me if I'm wrong. Regressions are show-stoppers,
but problems are not (if they were, we would never be able to


More information about the pacman-dev mailing list