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

Rpm option descriptions begin with lowercase letters, follow suit in rpmspec

Only queryformat is relevant for specfiles
- Instead of including the entire rpmQueryPoptTable in rpmspec and
  showing several bogus options, support --qf/--queryformat "manually"

Support overriding target for rpmspec queries too

Support both binary/source queries in rpmspec tool (RhBug:540807, ticket #89)

Add support for querying source rpm from spec too
- Handle source rpm query as a new query source type RPMQV_SPECSRPM,
  rename the binary query to RPMQV_SPECRPMS, with RPMQV_SPECFILE
  as a backwards compatibility alias to RPMQV_SPECRPMS.

Add a python accessor for the source header

Make the source header visible to python code.

Add a getter for the source header.

It appears the access to the source header has started to get buried
into usability so add an getter so the implementation can change a
little without breaking callers.

Fix misc/ include path
- -I$(top_builddir)/include/rpm was never right, and now with fts
  moved into misc/ this shows as rpm/rpmutil.h not getting found.

Further split the cli-tools to rpminstall, rpmquery and rpmverify
- Installing/erasing packages, querying and verifying require different
  amount of privileges on the system. Having separate binaries for
  these functionalities permits limiting the capabilities through
  SELinux and other similar security mechanisms: for example quering
  needs much less privileges than installing.
- For now, leaving /bin/rpm to be the Swiss Army knife it
  always was: capable of install/erase, query and verify. Eventually
  it should be turned into just a dumb wrapper which just execs
  the per-functionality binaries, but leaving that for later stage,
  as popt exec/aliasing doesn't quite seem to up to par with the task.
  Having the separate binaries available at least makes it possible
  for callers to specify the amount of privileges they need.

Remove filesystem related leftover API definitions
- This should've been in all the way back in
  commit 51c96db0464f86901b328899106dd8d4159dd878

Use the right variable for absolute path (ticket #137)
- Fix the problem where rpm attempts to use the tarball as the specfile

Fix generating platform config for arm
- We need to generate platform/arm-linux as well, not only all substitutes.

Require file attribute config to have .attr suffix
- Allows for more precise globbing, avoiding potential issues from
  leftover / accidentally placed files in the fileattrs directory.

Replace __foo_exeonly attribute with a more generic mechanism
- Use a list of text keyword tokens to allow for more flags without
  requiring adding special processing for every new flag we make

Tolerate NULL args in argvSplitString()

Add cli switches to override signing key and digest algorithm

Adjust rpm.pc private libraries
- we no longer have sqlite3 lib ever, but we might have lzma/xz libs

Further streamline rpmcliArgIter() and friends
- Turn applyFilters() into match iterator initializer which optionally
  applies filters if present
- Handle NULL iterator error codes centrally in rpmcliShowMatches()

Lift specfile query out of main rpm(query) into separate binary
- Avoids having to link /bin/rpm with librpmbuild and everything it
  might bring in (eg libmagic) which are not needed for core operation.
- Minimally preserve backwards compatibility with popt exec alias

Simplify queryformat popt callback handling
- No need to separate single vs multiple queryformats,
  rstrcat() works for both cases. Whether catenating multiply specified
  queryformats make sense is another question though...
- This can't get called with NULL arg (or then popt screwed up its
  argument checking), dont bother checking.

l10n: Updated Polish (pl) translation to 100%

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

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

l10n: Updated Italian (it) translation to 100%

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

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

And now python bindings are really free of librpmbuild internals
- Just one leftover offender in the form of forgotten type rename
  from commit 675bfca5cc300105f7859f028cc00ea036e72966

Kill spec.buildRoot from python
- We /could/ of course add a getter for this but ... sorry folks, what
  rpm happens to use as buildroot internally isn't anybody elses
  business.

Use the new spec section getter in python bindings
- Whee, for a change more lines removed than added...

Add getter for spec script sections too, bah...
- Pretty dumb and all, but to avoid breaking some python users
  (some folks apparently have found /some/ use for these...)

Use the new spec src/pkg API in python instead of direct access to spec

Add minimal API for spec packages and sources
- Iterators for both (these could easily done as self-iteration over
  ->next but to keep the api similar to other rpm iterators...)
- Minimal getters to satisfy python bindings needs

Use namespaced names for spec pkg and source opaque typedefs
- Leaving the painful and somewhat pointless exercise of changing
  all the Package and Source references for another rainy day