Comment 4 for bug 638618

Let's try a reality check, shall we?

The savings in removing duplicates in RPMTAG_DIRNAMES is infintessimal. Do the math ...
E.g. the savings is (at least) an order of magnitude smaller than the added overhead
of attaching file capabilities to *every* file so that perhaps 100+ files can be installed
with capabilities.

The data in RPMTAG_DIRNAMES has *never* been guaranteed to be sorted. Examples
of unsorted RPMTAG_DIRNAMES are everywhere.

Pursuing a sort order for RPMTAG_DIRNAMES hardly changes anything. Unsorted
RPMTAG_DIRNAMES will remain in *.rpm packages forevermore. So rpm wil
continue to have to sort RPMTAG_DIRNAMES if bsearch is desired. Luckily, there's
no access on any critical path in rpm that would benefit from pre-sorted
RPMTAG_DIRNAMES.

There is no benefit -- to rpm, to developers, to Red Hat, to LSB, etc -- from
sorting RPMTAG_DIRNAMES. Nor are there any forseeable benefits from
a Newer! Better! Bestest! implementation that I can conceive of even after smoking
a lot of crack ...

Using a B-tree, or a data structure, to achieve a 1-pass generation of simultaneously
sorted RPMTAG_DIRNAMES and RPMTAG_FILENAMES with a RPMTAG_DIRINDEXES lookup
is just bleeping overkill. At least do the sort by embedding OCAML or using an Oracle
database optimized for parallel retrieval or something manly please ...