[pacman-dev] little error when installing/upgrading the first package in a new database

[Xavier]

On Wed, Jul 04, 2007 at 11:51:22PM -0400, Dan McGee wrote:
> I don't know if you have ever peeked at the kernel source before, but
> they use some tricks for this kind of thing. Instead of setting the
> PKGCACHE to NULL to represent both empty and uninitialized, they
> #define a separate value such as EMPTY to be some other memory
> address. Thus you can test for either NULL or EMPTY. Can't remember
> exactly where this is done, but look at the kernel's list.h. Does this
> seem like a smart thing to do? I'm sure there are other cases where
> this could be useful, but I'm not sure.
>
> -Dan

Well, I guess that's the main thing to find out, seeing if it could be useful
in other cases.
But if the plan is to eventually move to kernel list, would it allow this
disctinction ?
I looked at your kernel_list branch, here is a part of the commit :

+/**
+ * list_empty - tests whether a list is empty
+ * @head: the list to test.
+ */

But I'm quite confused by this :

+/**
+ * list_del - deletes entry from list.
+ * @entry: the element to delete from the list.
+ * Note: list_empty() on entry does not return true after this, the entry is
+ * in an undefined state.
+ */


Anyway, this would fix the problem I was describing, but I wonder if it
wouldn't just hide it.
Is it really safe to assume we are using an outdated cache
(not containing the partial entry we are installing) ?
Or maybe, we should just check when alpm_pkg_get_depends return NULL, and
skip these partial entries ?

Otherwise, we could try avoiding partial entries, ie installing .INSTALL and
.CHANGELOG in the database only when we are actually writing the entry to the db.
But well, I'm not sure how easy that is.