Representing Architectures in libdebctrl

[Jonathan Yu <jonathan.i.yu@gmail.com>]

Hey all:

I'm currently stuck on how to represent architecture information in
libdebctrl. Currently I've considered an elaborate system where:

an Architecture is a struct with fields:
  char *name;
  int flags;

The name part is the architecture name, like "i386" or "any" or
"solaris" -- these are all validated according to the values provided
by dpkg-architectures -L, but will also accept other arbitrary
architectures (though it will issue a warning)

Now, if you've got a collection of architectures, like: Architecture: i386 amd64

I'm stuck on how to represent that. My first thought was just a linked
list of the aforementioned Architecture structs, which works, but
makes error reporting somewhat difficult, due to the way that error
reporting is done in libdebctrl.

Here's a brief primer on how error reporting works:

1. Every stage that could have an error has a linked list which is an
error stack
2. Every time an error is encountered, an Error object is pushed to
the end of that stack
3. Users check if errors have occurred using "has_error" on that stack
4. If users are interested in what errors have happened, you would
look at that stack
5. Languages which support exceptions would check has_error for every
operation, and throw an exception containing the top error on the
stack

The problem with this is that each Architecture list would need to be
passed a pointer to the error stack in order to add to it... which
makes it sort of complicated to work with.

As I mentioned above, the error reporting is made a bit difficult
because it means every operation would require an error stack to be
passed as well, which looks pretty bad for the user. It doesn't make
much sense to do:

platform_new(error_stack, arch_list_object, "i386");

where error_stack is a GList of Error objects
and arch_list_object is an ArchitectureList pointer (which right now
is just a GList)

However I'm at a loss for how I could more simply implement such a feature.

Any insight anyone could offer on what I might be able to do would be
greatly appreciated.

Cheers,

Jonathan