As promised some comments to your patches. While beeing offline (in
some talk rooms) I was bound to some local checkouts of tasks files that
were featuring a syntax bug (forgotten ',' to separate dependencies). I
handles this by an error message inside the importer log and in addition
tried to import this as well. So the importer code has changed and I
also cherry picked from your patches and commited to UDD git (so please
`git pull`).
Moreover I tried to run your code for filling up the alternatives table
and think it is not what you finally want to use to create the
metapackages. As far as I see you are injecting only thosedependencies
into the table that actually are containing alternatives (== are
containing a '|'). IMHO this will just create trouble for the
metapackage creation because you finally need to look into two tables to
assemble the dependency string and you also need to make sure that you
will not duplicate things. That's not what I would call easy or
reliable. My idea was to fill *all* dependencies into the new table and
you can look up single dependencies and alternative dependencies
straight from there.
To some point I had this implemented on my local instance but beeing
offline sometimes enables you to think twice before commiting and so I
stumbled upon the fact how to later calculate the resulting rependency
of a set of alternatives.
I'm not fully made up my mind about this. Finally the decision is
whether at least *one* of the alternatives is in Debian main for a
given architecture to put the "Recommends" label onto this. The
thing is that if we are storing strings inside the column of the
database you can not really easily query for it using SQL.
If we would decide to store a n array (PostgreSQL type) we could
possibly handle this better via a single query. On the other hand we
could stick to the "store a string of alternatives" into the database
and do the verification whether for a given architecture at least one of
the alternatives exists later on inside the Python code that creates the
control file (for the tasksel input file we are out of trouble because
we can use the existing table without the alternatives).
I hope I made my point clear - which I personally doubt ;-). Because if
this doubt I consider to implement the importer according to my vision
how it might be helpful for the control file creation and let you check
out whether you agree to my arguing that this table content is most
helpful for the given purpose. I think I will easily find the time
to do so until tomorrow.
Meanwhile I'd recommend you might look into the source of the openjdk7
package how the different control files for the different architectures
are created there. Perhaps this might give you an idea because it seems
even after my rewording on debian-mentors there was no helpful answer to
your question.