RFE: Add index with Epoch/Distepoch/Disttag

Considering that you mention epoch, do you think of different from Nvra?

For the issue with disttag & extra '-', I'm thinking that choosing a different separator might the best option, with perhaps some additional restrictions on allowed characters in disttag & distepoch to be able to split them as well..

A database index with different keys is what is needed.

And going "forward" RPM needs the ability to create tables
for whatever purpose is useful without waiting a decade
for distros to be able to be able to accommodate what is
in fact an utterly trivial engineering change.

But you are correct in recognizing that the Nvra index is
special because it contains a parser on the keys. What is
usually done in database programming is called a join, and
then there would need to be an index for each of the elements
in the tuple of {N,E,V,R,A,DE,DT}, and then a join using several
more tables, and with patterns that could be applied to each of
the multiple tables independently, would be done.

This is equivalent to writing an SQL layer onto Berkeley DB, and so
a different implementation, using the stem of a pattern as a
partial retrieval key on a single Nvra (Nevradt} string is being
attempted, with the tuples concatenated to form a string against
which the pattern can be applied.

Short answer: At the moment the Nvra index doesn't contain the
values you want to apply patterns to. this is the primary flaw.

Whether that is done by changing the existing Nvra index, or by creating
Yet Another Name ofr a new index is less important. It will be much
easier to change the Nvra index than to add the logic to chosse whether
Nvra or Nevradt index is intended.

At some point pattens will ned to be applied to all tables, not just Nvra. But none
is using the existing pattern matching retrieval or proposing as RFE.

 The issue isn't what separator is used, but rather whether a pattern that
can handle missing values can be written to be applied to the keys.

The separator is important only in so far as the Nvra key is displayed to users
exactly as found in the index on some code paths, and so aesthetics kick in.

But all the implementation needs is a representation that is sfficiently predictable
that a pattern with optional values etc can be written.

There are other and deeper constraints too. E.g. Epoch: should NOT need to be displayed
to users imho; if anything, Epoch: should be removed from the dstro entirely to
simplify identification naming with one fewer detail.

I also think that the massive redundancy in Distag/Distepoch need not be displayed
everywhere as part of the identification name, but that's up to you and Mandriva.

This is ultimately why the Nvra index as implemented doesn't contain any of
Epoch/Disttag/Distepoch. But if you MUST have all of those items, then
database operations, not tertiary lookup on retrieved headers discarding
items that do not match your access criteria, should be done as the correct engineering.

punting to rpm-5..4.11 (after sqlite3/odbc merging)