(aside) The "arbitrary" in the Subject: is misleading, there's hardly  
any
arbitrariness associated with parsers and syntax and grammars and  
formats.

In order to finish an implementation that explicitly maps DEB <-> RPM  
dependencies,
I need to commit to a syntax for parsing Depends: and/or Requires:  
from a spec file.

Specifically, that means I want to permit either of the following in  
*.spec files as synonyms:

For RPM
	Requires: foo >= 1:2.3-4

For DEB
	Depends: foo (>= 1:2.3-4)

(Note: there are many other issues, such as whether "foo" is a  
package (or not), whether
alternative choices or ranges are permitted, and whether a comma is  
significant (or not)
etc etc. No need to remind me.)

During the last month, I've added the default configuration to parse  
DEB tags like
	Depends:
as arbitrary tags with RPM. What that means is that a tag number is  
assigned using a SHA1
digest of the string "Depends", and the text after the tag is added  
as an element in
a string array as value.

The next step is to parse the text "arbitrarily", and reassign the  
parsed tuple of (in RPM
terms) {N,EVR,F} onto a set of arbitrary tags. In RPM terms, the tags  
are #define's as
     RPMTAG_REQUIREFLAGS         = 1048, /* i[] */
     RPMTAG_REQUIRENAME          = 1049, /* s[] */
     RPMTAG_REQUIREVERSION    = 1050, /* s[] */
but for the development interim I shall likely target the arbitrary  
tags attached to the strings
     Depends(N)
     Depends(EVR)
     Depends(F)
instead. Changing the assigned tagno's is rather trivial when  
eventually needed.

In order to attach DEB <-> RPM dependency syntax arbitrarily, I'm  
going to attempt to
use regex's defined by macro(s) in RPM configuration as parsing  
patterns. There's clearly very
little difference in the explicit syntax (so what's all the RPM <->  
DEB fuss about? ;-)
used to represent either Requires: or Depends: flavored dependencies.

So I'm looking for suggestions of how the parser configuration  
patterns/mapping
should look. If left to me, I will add/expand macros as needed, with  
conventional
macro naming used to generalize from instances to a class of  
arbitrary tags
parsed with attached arbitrary syntax (i.e. regex patterns).

Opinions?

73 de Jeff