Add rough-cut man-pages for our new executables
- Chainsaw relevant information out of rpm.8 and tweak a little bit,
  adding cross-references etc. These will need a lot more love though...

More ancient cruft removal from the repository

Lose ancient lclint remnants from the repository

Eliminate unused truncStringBuf() function
- This has been unused at least as far back as rpm 4.4 actually...

Eliminate unused spectag and speclines goo from spec
- These were used, back in the day, to implement a hidden --specedit
  switch, which in all its glory did: print a copy of a spec file,
  with group, summary and description looked up from specspo.
  This huge pile of junk was left behind from kicking out the
  useless "feature" in commits 7b95061d3b77d8e6b3c80e856b66f49b393511ba and
  0f991a14209054da7c45c46e96750738fc62874d.

elfdeps: Fix version definitions processing

The elfdeps doesn't parse the whole .gnu.version_d section.
For example:

$ readelf -V /lib/libbz2.so.1 | grep -A3 .gnu.version_d
Version definition section '.gnu.version_d' contains 2 entries:
  Addr: 0x0000000000000884  Offset: 0x000884  Link: 4 (.dynstr)
  000000: Rev: 1  Flags: BASE   Index: 1  Cnt: 1  Name: libbz2.so.1
  0x001c: Rev: 1  Flags: none  Index: 2  Cnt: 1  Name: BZLIB_1.0

Before changes:

$ echo /lib/libbz2.so.1.0.6 | /usr/lib/rpm/elfdeps -P
libbz2.so.1

After changes:

$ echo /lib/libbz2.so.1.0.6 | /usr/lib/rpm/elfdeps -P
libbz2.so.1(BZLIB_1.0)
libbz2.so.1

Signed-off-by: Alexey Gladkov <gladkov.alexey@gmail.com>

Fix the remaining enum abuse over rpmParseState in librpmbuild
- rpmParseState uses might actually qualify for a true enum here
  but changing it would require changing half of librpmbuild and
  many of them mix the parse states, other error codes and whatnot
  in their types... just not worth the trouble, so use an int.

Now, make getStringBuf() return const char * for correctness sake

parseScript() const pedantry
- The string from getStringBuf() is not modified, so use a const
  variable for it, and a separate variable for the temporary
  line splitting for triggers

Use ARGV_t instead of stringbuf in changelog parsing
- addChangelog() is a bad boy and modifies the string it grabs
  from getStringBuf(), be clean about it and grab a copy through
  argvJoin() instead
- addChangelog() would be better off walking and parsing over the
  argv directly instead of a joined string of it all, but leaving
  that exercise for some other rainy day

Use ARGV_t for temporary line storage directly
- Similar to commit 1e3db59b568b1ff7f7e1f3285fc9b18567f2f2d6,
  no point using temporary string buffer when only end up splitting
  it into an argv for processing. Incidently this would've been
  a much less intrusive fix to RhBug:573339 than introducing
  a whole new argvSplitString() function... oh well. Take care not
  to introduce extra newlines in the process as argvSplitString() was
  eating them before - need to use appendStringBuf() for spec->prep now.

Pass the script to doScript() as const char *
- doScript() doesn't do anything special with the script buffer,
  this lets us use const for the argument.

Argument passing hysteria in doScript()
- Callers know perfectly well which part they're passing to doScript()
  so they can just as well pass in the name and the scriptlet to run,
  avoiding silly stuff in the switch-case

Handle NULL sb in getStringBuf() cleanly

Use ARGV_t for package fileFile, fileList and policyList
- Similar to commit 1e3db59b568b1ff7f7e1f3285fc9b18567f2f2d6,
  all these end up being passed to argvSplit() to process them line
  by line in the end, collect them in the argv to start with saving
  a whole lotta huffing and puffing in the process

Eliminate splitString() leftover braindamage in processSourceFiles()
- Collect the filenames directly into the ARGV_t files instead of
  putting them to a StringBuf first and then argvSplit()'ing the
  result, doh. Leftover stupidity from eliminating splitString()
  usage in commit 94ff22b129aeb31c38848231e40f87aa4a5613a1

Bury stripTrailingChar() inside the only remaining user
- There used to be some other callers too but seems they've passed
  away, leaving just the relocation code in rpmte.c. Which  means we
  can get this ugly bit out of the API.

Bury StringBuf inside librpmbuild internals

Make rpmfcExec() internal
- Nobody in their right mind is likely to be calling what's really
  an internal helper function in the build code. Simply missed in
  the first round of librpmbuild API butchery.
- This eliminates the last remaining exposure of StringBuf in the API

Eliminate the sole StringBuf user in librpm side
- Using ARGV_t here might not be exactly optimal but then manifest
  parsing isn't exactly performance critical either.

Fix BDB version check in configure to work with >= 5 too

Separate match iterator allocation vs initialization
- There's exactly one spot within rpm which needs the former behavior
  of rpmdbInitIterator() on a secondary index with keyp of NULL:
  rpmFindBaseNamesInDB(): it wants an empty iterator on RPMDBI_BASENAMES,
  which is then extended as it progresses. Starting with commit
  c70e076e088589f65160c05ee7cc8db0b3db6d7e, rpmdbInitIterator()
  however returns the actual index in that case, which is not
  optimal for rpmFindBaseNamesInDB(). Handle the basenames in db
  as the special case it is, and have it explicitly create an
  empty iterator with the new call.

Create less draconian loops for grouped collections
- Instead of creating a completely unresolvable tangle of pre-requisites
  between all collection members and their requirements, just add
  a single relation loop of all the packages in a (grouped) collection,
  effectively turning it into a strongly connected component. The
  loop-cutting algorithm has slightly better chances of surviving this
  while still enforcing the collection members to be installed in one
  lump. Also only process each collection just once.

Only specific cases of collections need extra ordering
- Add a crude flags system to allow selectively enabling the extra
  grouping during ordering: currently only sepolicy collection needs
  this, and its very harmful when applied to more regular collections
  as it creates truly gigantic dependency loops that rpm has no chance
  of sorting out sanely.

l10n: Updated Polish (pl) translation to 100%

New status: 741 messages complete with 0 fuzzies and 0 untranslated.

Transmitted-via: Transifex (www.transifex.net).

Eek.. librpmsign sources went missing in the move
- Re-adding the files that should've gotten moved (not removed) in
  commit 9f2c1bd9096cbf382c864737a6565e5487767ce2
- Mild wtf ... probably user (not git) error though. Too bad the
  broken state got pushed already :-/

Bah, couple of missed places for librpmsign moving

Teach python about the new RPMDBI_* tags

Update translations to pick recent changes + files moving about

Move librpmsign to its own subdirectory in the sources

Brute-force s/rpmTag/rpmTagVal/ in entire librpmbuild
- Many of these cases would be true enums from preambleList & similar,
  except for the list terminating sentinel. Just switch all the
  remaining rpmTag's to rpmTagVals to bring our enum-whacking to
  a grande finale.

Fix invalid uses of rpmTag/rpmSigTag in pack.c

Replace remaing rpmSigTag uses with rpmTagVal
- Some of these might actually be "correct" but about one case from
  librpmbuild cascades down here ... just not worth the trouble to
  keep the as rpmSigTags.

Use header datatype for hash algo instead of pgpHashAlgo enum
- The digest algo can come from macro numeric expansion which is
  not an enum. Just use uint32_t which is how it'll end up in the header

Eliminate pgpHashAlgo uses in librpm side
- In all these cases the value comes from a non-enum source so
  just use an int instead

Fix (ie eliminate) rpmSigTag uses in rpmchecksig
- The sigtags originating from headers are not enums but integers
- 0 is not a valid rpmSigTag value while the other cases would be in
  bestSig() and friends

Meh, one missed rpmTag -> rpmTagVal change in query
- While the initial assignment is to true rpmTag, rpmTagGetValue()
  returns rpmTagVal, not rpmTag.

Couple of enum craziness fixes to package.c
- 0 is not a valid rpmSigTag, just use rpmTagVal instead
- use int instead of pgpHashAlgo for temporary variables, the
  originating data is not "pure" enum

Eliminate use of pgpHashAlgo in rpmio interface arguments
- While its use would seem kinda obvious here, in rpm context this
  information often comes from header tags which are plain integers
  and would require conversion/casting to the enum. What matters is
  the integral value, not it being actual enum.

Couple of previously missed type changes in rpmdb code

Switch lowelevel header internals to use rpm_tagtype_t for tag type data

Switch python bindings to use rpm(Dbi)TagVal as appropriate
- None of these are true enum uses as the value typically originates
  from python integers etc.

Change all internal uses of rpmtsInitIterator() to use DBI tags

Switch lone rpmTag use in query to rpmTagVal

Switch psm and rpmscript to use rpmTagVal where appropriate
- There are a few true rpmTag uses though, leaving them as they are...

Change rpmfiNew() tag argument to rpmTagVal
- The argument is actually unused, but that only makes it even more
  stupid to require C++ callers to potentially having to cast.

Switch rpmte API and internals to use rpmTagVal instead of rpmTag
- Except for rpmteColorDS(), these can get called with intergral
  value instead of the actual enumeration

Switch rpmds API and internals to use rpmTagVal instead of rpmTag
- None of these require passing "true enum", the value is what counts.
  In general, enums as function argument types are just a royal PITA
  from C++, avoid when not strictly necessary.

Change rpmdb internals and iterator APIs to use the appropriate tag types
- The actual indexes are rpmDbiTags, and the tag passed to
  rpmtsInitIterator() and rpmdbInitIterator() always refers to a
  database index, not arbitrary header tag. The tag passed to
  rpmdbSetIteratorRE() however /does/ refer to a header tag. This rather
  important distinction can actually be expressed in the API.
- As the indexes are generated from header tags of the same value,
  most of these need to use the TagVal types instead of actual enums
  to avoid mismatches - the value is what counts, not it being an enum.
- Several places still have variables misleadingly named "rpmtag" when
  they refer to dbi tags, but leaving them for now to avoid excessive
  changes at once.

Document our supported rpmdb indexes in the API via an enum of their own
- Now that our indexes are actually hardwired in the code we can
  properly separate rpmtag vs db index names.
- Defined similarly to rpmTags, with rpmDbiTag being the "true enum"
  and rpmDbiTagVal the integral type they present. As many of the
  indexes are defined via RPMTAG values (and need to remain that
  way to avoid breaking every single API user) we need to have a
  compatible type with rpmTags.
- These would logically belong to rpmdb.h but keeping in rpmtag.h
  to have them available "everywhere", we can't go including rpmdb.h
  from rpmtag.h so keeping them here avoids potential unnecessary breakage.

Change all the legacy interfaces to use the "concrete" integer tag types
- More compatible with the 4.4.x definitions (should've been this way
  all this time) and none of these are "true" enum uses anyway

Switch header APIs to use rpmTagVal instead of rpmTag
- The header getters are used for both signature header and the "normal"
  header, and even beyond that there's no requirement for a tag in
  the header to be part of rpmTag enum. The headerPutFoo() variants
  technically do require the tag to be found in the tag table (ie be
  an rpmTag) but they still operate on the integer value, they dont
  require it to be a "true" enum.
- Inside tagexts.c there are a few "true" enum uses in the
  internal helper functions, leave them be.
- While this technically changes some the most commonly used API's,
  this wont affect callers really: if the callers were using an enum
  before, enum can always be cast naturally to an integer. The other
  way around was the problematic part (ie the braindamage we're fixing
  here now...)

rpmTagFoo() getters take arbitrary integers, not rpmTag enums
- Another step to clean up the enum braindamage...
- rpmTag values are the only values that will be found, but it doesn't
  mean the values passed are rpmTag enum members - eg anything from
  a header is not. rpmTagGetValue() does come close to returning true
  enums, but there's RPMDBI_PACKAGES and then RPMTAG_NOT_FOUND, neither
  of which are actually tags.
- Introducing a new rpmTagVal typedef. It's just an alias for the
  "lowlevel" rpm_tag_t type but visually more in line with the other
  rpmTagFoo bits - to be used with the "higher level" tags whereas
  rpm_tag_t is the "physical" type. Not that it makes any difference...

Use concrete integer types for entryInfo and rpmtd members
- Start undoing self-introduced enum braindamage from 2007: the lowlevel
  tag data in header structures are NOT rpmTag/rpmTagType enums, but a
  32bit integer of any arbitrary value. While these can be legally mixed in
  C the same is not true of C++ and even in C using enum here is not "correct"

Couple of doxygen argument mismatch fixes

Eliminate silly cast

Drop unused pubkeys index too
- This isn't expensive to create but unused is unused is useless junk.
  Rpm < 4.6.0 did use this a lot, but nowadays we preload the keyring
  and do key lookups from meory so this isn't needed for anything.
- 'freedata' argument of td2key() is now unused, but leaving it there
  as we might need tag data -> index data transformations in the future.

Drop filedigests index
- Now that the sole "user" is gone, kill the stupid index. Speeds
  things up considerably: eg on database rebuild, the file digests
  index generation amounts to roughly one third (!) of the entire time.

Eliminate useless --fileid query selector
- Finding out which package provides a file with a given digest
  is just .. useless functionality. Being next to useless is one
  thing, but we pay a high price for this particular uselessness:
  the index needed for this is one of the biggest and most expensive
  indexes we have.

Fix Python bindings and raise KeyError when there is no index for the given tag

Fix typo / erroneously deleted line

rpmdbKeyIterator: loop over keys in the database indexes

Hardwire the fundamental BDB access method configuration inside rpm
- The different access methods have different capabilities and are not
  interchangeable in all situations. Currently we can use either
  hash and btree but this might not be always the case for all indexes.
- We'll eventually want to force-switch the index types to our liking,
  but for now follow these simple rules:
  1) For existing databases, we accept both btree and hash
  2) For newly created databases, the main Packages database remains
     a hash, all indexes are btrees.
- Rip out nearly all the rest of the remaining macro configuration.

Eliminate now unnecessary db rebuild macro goo and other leftovers
- Rpm knows how to handle db rebuilds by itself, no need to expose
  these bits to configuration.
- Also rip out a pile of other leftover "documentation" about BDB
  internal switches.

Lift fsync enable/disable configuration handling to rpmdb layer
- Add a fsync disable/enable function in the backend, call from
  rpmdb layer: on initial database creation (including database
  rebuild), it's "safe enough" to disable fsync as there's no former
  data to protect. Considerably speeds up initial install to eg chroots.
- Always re-enable fsync when closing a read-write database - at that
  point there /is/ data to protect.

Hardwire the fundamental BDB subsystem configuration inside rpm
- BDB subsystems are not something that can be just switched on and
  off like that. If we want to support different configurations they
  need to be rpm-specific settings such as transactional/concurrent
  setting, not an arbitrary pile of flags that cause stuff to blow
  up when abused.
- Eliminate dbi->dbi_eflags completely, the environment opening flags
  can be fetched from BDB where needed. Subsystem configuration from
  macros is no longer looked at or honored, but leaving the option
  table there for debugging output at least for now.

Lift missing index detection to rpmdb layer
- Avoids unnecessarily modifying the parent rpmdb from backend layer
  and since its the rpmdb layer that needs to deal with creating
  indexes anyway...
- Also avoids bumping the counter in case of errors (eg permission denied)

Avoid umphteen unnecessary calls to rpmTagGetName()
- These aren't exactly hotpaths, but since the dbi always knows
  its name already there's no point going through rpmTagGetName()
  bsearch()'es and all for these.

Add a getter for dbi name

Clean up rpmdbOpenIndex() logic a bit, no functional changes
- dbi is guaranteed to be NULL on non-zero return from dbiOpen(),
  dont bother triple-checking and freeing NULLs
- rearrange the success case a bit to pave way for other things that
  we'll want to do here

Lose leftover, unwired pagesize db option
- db->set_pagesize() got semi-accidentally nuked in commit
  f2957887fb7f80c2dbf6f0b4973c72ca66b0d2e8 but we really dont want
  folks to mess with this anyway - filesystem I/O block size is generally
  the best performing and safest option here.

Avoid directly accessing bdb-specific dbi members from rpmdb layer

Add a backend-independent flags + getter for dbis
- Keeping up pretense of being backend independent where its easy
  to do... and rdonly+created status are rather obviously universally
  mappable

Pass rpmdb, not dbi to db_init() and db_fini()
- These are global operations and dont need the individual dbi for
  anything but finding the parent rpmdb. Another step closer to
  decoupling db environment from dbi's...

Add a no-dbi version of the db error reporting function
- cvtdberr() only needs the dbi for figuring out the rpmdb api level,
  split this part out to separate function so we dont need to carry
  dbi's around where they dont belong

Move db environment-level configuration out of per-dbi structs
- Carrying global configuration in all dbi's is just dumb. First
  step towards fixing the stupidity.

Group the database options to per-dbi and per-environment groups
- No other changes

Python dbMatch() doesn't take (or need) len argument, fix the docs

A few more rpmdb variable/argument renames, missed in previous round

Decouple dbiVerify() from dbiClose()
- When RPMDB_FLAG_VERIFYONLY is set, dbiOpen() now only creates and
  returns the db handle without actually opening it. With this we
  can sanely implement dbiVerify() as its own separate functionality,
  also avoiding the need to have duplicate code for creating and
  tearing down the db environment (which in turn kills our ability
  to use DB_REGISTER if/when the day comes)

Add flags argument to dbiOpen(), pass through from rpmdbIndexOpen()

Oops, dumb copy-paste error causing --verifydb to --rebuilddb instead

Rename rpmdb variables in the backend to rdb to distinguish from its type

Generate missing database indexes automatically
- Now that we know whether backing files were created on open, we can
  easily detect the need for index generation too. As index generation
  requires expensive plowing through the entire Packages database, we
  to create all missing indexes at once instead of risking several
  loops over Packages. So if we spot a missing index, we open all
  our indexes and generate all the missing bits in one go.
- Berkeley DB does support on-demand index generation for secondary
  indexes created with db->associate(), but as rpm's indexes are in
  a slightly different format (they store tag index besides the
  header number), using it would require various other
  changes too. Also the BDB indexing callback recieves the data
  in serialized format, which in rpm's case would mean either
  headerLoad() for every single indexed bit, or passing the in-memory
  header through some other indirect means.

Create indexes too on rpmdbInit() (ticket #156)
- Seems strange to have an initializer function which doesn't
  initialize
- This leaves RPMDB_FLAG_JUSTCHECK unused...

Avoid returning NULL from prDbiOpenFlags()
- While glibc can turn NULL %s to "(nil)", this is not required in
  any standards. Avoid embarrassing segfault from a silly debug message.

Remember if we created the db backing file on open
- Instead of trying to figure out suitable flags beforehand, try to
  open the db a couple of times with different flags. This way we know
  whether the backing file was created on open or not. Also simplifies
  the flag shuffling somewhat.
- We also do this when O_CREAT db_mode, for the same reason: rpmdbInit()
  can be called on existing database too, and we want to know which
  of the files actually got created.

Lift dbi fcntl() locking out of dbiOpen()
- Just to make dbiOpen() shorter and easier to read, locking is
  different from opening...

Lift secondary index updating out of rpmdbAdd()

Support looping over indexes when giving keyp=NULL to rpmdbInitIterator()

Add python bindings for librpmsign
- Similarly to the build-bindings, permit import failures as librpmsign
  might not be installed and we dont want to force the dependencies
  into every single installation

Oops, fixup rpmsign exit codes on success

Make rpmPkgSign() actually honor the signing arguments
- For now just keyid string and hash algorithm supported. The
  macro fiddling should perhaps go deeper into the signing process
  but this'll do for now...

Nuke rpmcliSign() out of the orbit

Make rpmsign use the new signing interface (minimal conversion for now)

Add beginnings of a real API to librpmsign

Move plugins out of rpm config directory
- Plugins are by their very nature arch specific, while /usr/lib/rpm
  is a hodgepodge of all sorts of ... stuff, most of which is
  arch-independent and all. Use %{_libdir}/rpm-plugins to cleanly
  differentiate 32 vs 64bit plugin paths

Add 'VCS' key

Spec files have a lot of metadata about a project.  However one of the
most key components is the upstream version control system which was
notably lacking.

Resolve this by adding a "VCS" key.  There is no specification
for contents of this key, given that the set of version control
systems (and features thereof) are not well-defined.  However,
recommendations are:

 * git: This URL should be in a form that can be passed to "git clone",
   with the additional feature that an optional fragment identifier "#foo"
   denotes a branch or tag.

Add 'VCS' key

Spec files have a lot of metadata about a project.  However one of the
most key components is the upstream version control system which was
notably lacking.

Resolve this by adding a "VCS" key.  There is no specification
for contents of this key, given that the set of version control
systems (and features thereof) are not well-defined.  However,
recommendations are:

 * git: This URL should be in a form that can be passed to "git clone",
   with the additional feature that an optional fragment identifier "#foo"
   denotes a branch or tag.

Add --requires etc popt aliases for rpmspec too
- In addition to the regular dependencies, add --buildrequires
  and --buildconflicts which are just --srpm --requires and
  --srpm --conflicts in reality