Use RPMDBI_INSTFILENAMES on file queries as well

- This changes query behavior quite a bit as files with non-installed
  status are no longer returned as matches. The rationale is that
  it makes figuring out dependency issues with the "new" behavior
  more obvious (but perhaps we should have a switch to enable
  former behavior). Besides not satisfying dependencies, files with
  non-installed status are not really owned by the package, as they
  would not be removed on package removal.

Take advantage on RPMDBI_INSTFILENAMES in rpmdbProvides()

- No functional changes, we did the same thing "manually" here already.
  Only now the data is more conveniently available through API to
  other callers who might care (yum & friends)

Add a new pseudo index for actually installed files

- RPMDBI_BASENAMES (ugh) returns all headers with matching filenames,
  whether the files are actually installed or not, which can be
  rather misleading when dealing with file dependencies. The new
  RPMDBI_INSTFILENAMES only returns headers with matching filenames
  whose state indicates they are actually present on the system.

Generalize pseudo tag handling in rpmdbInitIterator()

- No functional changes, just makes the case where a pseudo index
  uses a differently numbered underlying physical db index more generic.

Use correct file state for colored file replacements

- On colored file conflict resolution, the non-preferred colored
  file state would depend on installation order: if non-preferred
  arch is installed first, and the preferred arch in another
  transaction, the non-preferred color would get marked "replaced"
  indicating a forced install when none was used. This fixes
  the file state in such cases to "wrong color" to be consistent
  of the other installation scenarios.

Add test for ts.clear() as a side-effect of add to ts test

Export rpmtsEmpty() to python as ts.clear()

- Why the heck hasn't this been exported before, duh?
- Method name clear() chosen as this appears to be emerging as a
  standard of sorts for this kind of operation: dictionaries and
  sets have it and list will get it in some python 3.x version.
  Additionally foo.empty() could easily be mistaken for "test whether
  container foo is empty or not" (especially those with c++ background...)

Remove support for ancient bzip2 library versions

- bzip2 1.0 is over ten years old by now, anybody still using versions
  older than that get what they deserve...

Remove unused FDFOO macros

Handle query format field width centrally in formatValue()

- Eliminate the quirky formatPrefix buffer argument to formatter functions,
  deal with the width at formatValue() if specified.
- This not only simplifies things a great deal, removes a nasty
  unbounded buffer writing from formatter functions and speeds things
  up somewhat by removing extra rasprintf()'s in many cases, it also
  gives us width formatting of everything including "error messages"
  like "(none)" and "(not a number)" which previously got dumped without
  any formatting.
- The cost of this is the loss of zero padding support for numeric
  data but that's hardly a big deal.

Take length of format width specifier into account for format string buffer

- Prevents buffer overflow in case of ridiculous field width specifiers
  like --qf "%100000000000000000000000000{name}". There's another similar
  static-sized buffer in rpmtdFormat() but there we're not dealing
  with user-speficied format strings so its okay even if ugly.
- The format string handling wants a bigger overhaul but this makes
  for a nice little backportable patch for starters.

Validate query format field width specifier is sane

- Only allow [[-]<number>] in the format field, users have no business
  telling which format conversion sprintf() should use for tag data.
  Fixes embarrassing segfaults from things like %s{size} which rpm
  has merrily passed on to sprintf() as-is.

Strip trailing slash from paths at addFile()

- Fixes regression from commit 23167c3ea459405c98d8e759993efb6d9b1ea7f3
  which causes all %dir entries to have a trailing slash, breaking
  at least dependencies on such directories and probably something
  else as well.

pgpVerifySig() check of NULL hash is the wrong way around

- NULL hash is pretty much a can't happen-case here but lets be
  sane if it happens afterall - NULL hash would be an error and
  we dont want to process the rest if that happened.

Restore %defattr() behavior on special %doc

- With the change in the defattr handling (commit 09efbe96), you also
  need to save the current defattr setting when processing %doc.
  Otherwise doc files will just get the value from the latest defattr line.

Fix misleading error message when gpg key is expired (RhBug:672727)

Sanity check signatures even if we dont have a key

- Fixes a regression originating all the way back from commit
  c7fc09d585ff3831924f72f61d990aa791f2c3f2 (ie rpm >= 4.8.0)
  where a package with a bogus signature can slip through undetected
  if we dont have a key for it.
- This additional sanity check on the signature prevents is enough
  to prevent the fuzzed package in RhBug:721225 from crashing us
  by stopping the bad package at the front door. That we don't have
  proper tag data validation is another, much wider issue...

Fix memleak on keys with more than one user id

- This is not "correct", we should permit more than one user id.
  Leaking memory is still worse than not leaking, corrent behavior
  or not.

Fix crash on PGP packets/armors with more than one key (RhBug:667582)

- While OpenPGP permits arbitrary number of keys per packet/armor,
  we can't handle more than one, error out early.  The poor user
  wont get much of a clue as to what went wrong, but thats still
  better than crashing and burning.
- Return NULL from pgpPrtPubkeyParams() on errors and pass it onwards
  from pgpPrtKey() which propagates it up to callers. Besides
  the crash, this also fixes the error path from pgpNewPublicKey()
  failures.

Oops, rpmPubkeyDig() should return NULL if pgpPrtPkts() fails

Only increment number of query/verify sources when we encounter new types

- This makes it legal to specify the same query/verify source more
  than once. Not that it makes a whole lot of sense to do so, but
  complaining "only one type of query/verify permitted at a time" seems
  silly as well if you're just (accidentally) specifying the same
  source twice. Besides, this makes the code a bit cleaner.
- Kinda related to RhBug:691930.

Fix the sanity check on number of query/verify sources (RhBug:691930)

- Prior to commit 2e672f3fae9d8ff7ee64ae13cfa2fe65272c2ede, the
  callback would get called twice for every option so the expected
  number of query/verify sources was doubled. Now the numbers
  match with reality, adjust the check.

Whoops, wrong variable passed to io debugging

Cleanup fdRead(), fdWrite() and fdSeek() a bit

- Remove unnecessary fluff, these are very simple operations
  and dont need any temporary variables, re-re-redundant NULL checking
  etc, its already done at the caller level.

Cosmetics: remove empty comments and such

Dont bother checking for NULL fd on stats collection

- All the places calling these are already checking for NULL fd,
  no point re-re-re-re-re-checking it

Centralize most of the debug goo as well

Just pass fd pointers around instead of "cookies" cast to fd

- There's not a whole lot of point passing our own data structure
  around in void pointers and re-re-re-re-re-recasting them to fd's
  again all over the place. Just pass the damn fd to begin with.

Centralize fd digests collection

- Instead of requiring every io type to remember to update digests
  on their own, do it centrally on Fread() and Fwrite().
- This changes the digest calculation on writes slightly: previously
  we calculated the digests regardless whether the actual write
  succeeded or not, now we do this similarly to reads and only
  update the digests on success.

Centralize fd stats collection

- Instead of requiring every io type to call stats on their own,
  simply call the stat updates from the main functions Fread() etc

Eliminate unused leftover bytesRemain member from FD_t

- This used to be relevant for remote io but now its just unused.
- Also remove the "simulate EOF" on NULL fd returns while at it,
  these seem simply wrong (considering Fread() and Fwrite() behave
  more like read() and write rather than fread() and fwrite())

Minor cosmetics cleanup to Fseek()

Return an error on Fread() / Fwrite() on NULL fd

- Merrily returning success on read/write on NULL fd just is not
  sane. If something breaks because of this then that something
  needs fixing instead...
- Also return code type was mismatching in both, these return
  ssize_t not int.

Implement Ftell() for zlib versions that support it

Add basic test for Ftell() in python

Use a vector for Ftell() functionality too

Remove pointless fdSeekNot() "not implemented" function

- Fseek() and friends already return -2 for not implemented functions,
  this is not needed at all

Add a simple test for Fflush() functionality in python

- Prior to previous patch this segfaulted and tracebacked...

Fix totally broken Fflush() operation

- This only ever worked for fpio, for all other types it returns
  bogons or crashes and burns.
- Use the file op vectors to find our fflush function instead
  of #ifdef/#endif if/else/ifelse jungle.
- Notably fdio and ufdio do not have a fflush() equivalent because
  they dont need one. Use a dummy function to always return success to
  differentiate from -2 aka "not supported by this io type"

Axe the broken fpio support for good

- The whole thing is extremely hacky and failing to properly take
  fundamental differences in eg fread() and read() semantics into
  account (the whole rpmio fd is confused over this: Fread() claims
  to be fread() clone but reads behave with read() semantics
  and we dont provide feof() equivalent etc), special cased all over
  the io code when vectors exist for this purpose etc (not that fpio
  is the only offender in that regard)... RIP. Nothing should miss
  this but if we'd ever want to add it back, it'd better be done
  right at least.
- This COULD silently break somebody's code if they rely on the broken
  special case semantics of fpio mode, but most likely rpm itself
  was the only thing using fpio (and relying on the behavior) and
  even then, mostly only to get a FILE stream pointer out of it.
  Now we'll just silently return a fdio descriptor, as we do for any
  unrecognized io mode... (another sigh)

zlib is mandatory, fail at configure if missing + remove conditionals

- Unlike bz2 and xz/lz, zlib compression is not tracked by any rpmlib
  feature and is part of the original package format really, zlib
  simply must be always present.

Eliminate the last two fpio uses in rpm codebase

- Both relate to reading manifests and it doesn't make the damnest
  difference what io mode these use as rpmReadPackageManifest()
  opens its own stream on the fd with fdopen() which works on
  any io type, not just fpio..

Eliminate the uuugly and stupid fdGetFILE() from the API

If we need a FILE stream then get one...

- Replace the hysterical "lets see if the temp creation gave an fpio
  fd (it didn't), if not open another fd and then get its private
  FILE pointer" fiddling: since we need a FILE stream then open one
  with fdopen(), duh. Grabbing a rpmio fd to begin with is stupid enough
  when all we want is a stream, but wanting to use rpmMkTempFile()
  functionality...
- Also fixes an fd+mem leak in the unlikely but possible case that
  rpmMkTempFile() succeeds but fdopen() fails.

Take advantage of Fdescr() in rpmReadPackageFile()

- If fn to rpmReadPackageFile() is NULL, use Fdescr() value to give
  more meaningful errors
- Change a couple of places where we haven't got a clue of the file
  name to take advantage of the above

Teach python rpmio bindings about Fdescr()

- Similarly to python file object having o.name, export Fdescr()
  as fd.name. Python uses <foo> for non-paths but [foo] seems like
  a safer choice wrt accidental redirections.
- Also add a basic testcase for fd.name

Remember path (or other description) in fd's, add getter

- If opened by path, we obviously want to use that. Otherwise
  generate a description lazily on first Fdescr() call: on Linux
  we can grab something relatively meaningful by looking up from /proc
  (this is why we want to be lazy here...). If that's not available
  or fails, just generate a string on the current fdno. Actual
  paths are returned as is, other descriptions are bracketed,
  (eg "[mumble 123]").
- This makes it possible to give more meaningful error messages in
  places where we only get an fd from somebody (related to RhBug:522160)

Eliminate fdNew() from the API

- Nobody should be able to create file descriptors which are not
  attached to a file/descriptor of some kind, the only sane
  fd constructors are Fopen(), Fdopen() and fdDup().
- The same applies to fdFree() but its a bit more complicated,
  punting that till later...

Further streamline & sanitize lead handling

- Never log anything from rpmLeadRead(), instead return an error message
  the callers can log if they see fit
- Add a return value for the lead type (which is the only bit of
  info from the lead we sometimes resort to using)
- Permit NULL pointers on all return values
- Eliminate rpmLeadCheck() and rpmLeadType() from the internal API,
  these are now combined into rpmLeadRead().
- Fix up the callers: only (re)signing needs the actual lead,
  signature verification only cares if its valid or not and
  package reading only wants the type from the lead (annoying but...)

Only bother mallocing lead for return if read actually succeeded

- Doesn't make much of a difference now, just paving way for next steps

Eliminate remaining assert()'s in rpmlead.c

- Blowing up with assert() on freeing NULL is just dumb...
- rpmLeadWrite() can easily be made to handle NULL lead gracefully

Make rpmLeadRead() return an allocated lead, fixup callers

- Requiring callers to allocate a lead "buffer" for reading into
  is just DUMB (greetings to self back in 2008, sigh). This avoids
  having to deal with freeing the lead in case the read failed, and
  allows getting rid of rpmLeadNew() completely.

Start beating a little bit of sense into the braindamaged rpmlead API

- rpmLeadNew() should not populate the struct, only allocate it
- The only case where we're creating new lead data is
  rpmLeadFromHeader(), move all initialization there, and add a comment
  for RhBug:717898. Also eliminate the stupid assert, we can
  easily handle NULL header here.

Add tests for header getattr() behavior sanity

Fix the broken python header  __getattr__() behavior, take 13 (or so)

- Tags as header attributes seemed like a nice idea at the time... but
  has been a PITA due to side-effects it causes, such as breaking
  getattr() use for "capability testing", eg:
      >>> h2 = copy.deepcopy(h)
      Traceback (most recent call last):
        File "<stdin>", line 1, in <module>
        File "/usr/lib64/python2.7/copy.py", line 172, in deepcopy
          copier = getattr(x, "__deepcopy__", None)
      ValueError: unknown header tag
- Since we can't really go removing the brainded feature (somebody might
  actually be using it) try harder to fix it: if its not an actual
  attribute, save the exception we got from PyObject_GenericGetAttr()
  and if its not a valid tag either, restore the original exception.
  This allows cases like the above __deepcopy__ to work properly.

Add __reduce__() method to python header object

- This allows header objects to be pickled and also copied correctly
  with python's copy.copy()
- Split the header to string-conversion into a separate helper function,
  used by the now largely unnecessary unload() method and __reduce__().

Revert the ds, ts, fi and spec python object creation commits

- Hasty push-finger syndrom, while its not exactly plain wrong to
  do things this way, it doesn't really make sense for these types
  either. Python's own file object permits reinitialization though,
  so leaving rpm.fd() the way it is now.
- This reverts the following commits:
  d056df28c38e602d82b4f9b527c686037074e660
  3f77c3146da46a49f44b17fa66139fbe2dd9e45c
  7214b2e0a271b7a7b3df312c58593878cbf56504
  dc50fb2863c81159fb4cc8b25ce3862720c0cce5

Bring back c++ "protection" to rpmsq, oops

- The beginning of c++ extern block went with the dishwater in commit
  269df02ae1fc3955bee4e5f471b1172c04c714e2

Fix/sanitize rpm.ds python object creation a bit

- Move all actual initialization work into tp_init, permit
  reinitialization without leaking and use PyType_GenericNew for tp_new.

Fix/sanitize rpm.ts python object creation a bit

- Move all actual initialization work into tp_init, permit
  reinitialization without leaking and use PyType_GenericNew for tp_new.

Fix/sanitize rpm.fi python object creation a bit

- Move all actual initialization work into tp_init, permit
  reinitialization without leaking and use PyType_GenericNew for
  tp_new, eliminate internal rpmfi_Wrap() use.
  There's one user for rpmfi_Wrap() in rpmte-py.c which needs fixing
  later...
- Remove unused fiFromFi() helper function

Fix/sanitize rpm.spec python object creation

- Specs are not really immutable, move the initialization work into
  tp_init and use PyType_GenericNew for tp_new since we're not
  doing anything special there.
- Eliminate the stupid spec_Wrap() thing and hide specPkg_Wrap()
  out of side (TODO later...)

Add a simple and stupid test case for python spec parse

Fix/sanitize rpm.fd python object creation

- FD's are not really immutable, move the initialization work into
  tp_init and use PyType_GenericNew for tp_new since we're not
  doing anything special there.
- Remove half a dozen different unnecessary exit points

Fix the totally broken rpm.fd() read method

Add basic test for rpmio python bindings

Fix explicit directory %attr() when %defattr() is active (RhBug:481875)

- parseForAttr() doesn't know whether it's dealing with a directory or
  a file, so it can't know which defaults it should use.
  Move all the decision making on which of the explicit/default/implicit
  attributes into addFile() where we do know what kind of entry we're
  dealing with, and only parse in parseForAttr().
- Update the test-case status to expect success now.

Add a test-case for various %attr and %defattr combinations

- Currently this fails expectedly due to RhBug:681540 on the last
  directory of the test rpm.

Enable GLOB_ONLYDIR of the bundled glob() on platforms that support it

Pay attention to dir vs file when building (RhBug:505995)

- Preserve trailing slash if it exists, and also add one on explicit
  %dir entires. This lets rpmGlob() and friends to skip any matching
  files that might be present, fixing both test-cases in RhBug:505995.

Honor trailing slash in rpmGlob()

- Only return directories if a pattern contains a trailing slash.
  Use GLOB_ONLYDIR hint if available but as this is unreliable,
  we need to stat the paths to be sure.
- Hysterically enough, rpm bundles its own copy of glob() which does
  have GLOB_ONLYDIR but ATM it doesn't get build because HAVE_D_TYPE
  isn't defined outside glibc build environment which is where our glob
  originally came from...

Remove ugly isDir recurse prevention hack on build

- We know if we're already fts-walking by the way addFile() gets called,
  dont corrupt fl->isDir for no good reason.

Eliminate static BUFSIZ use in filelist parsing

- In the unlikely event of filelist line being longer than BUFSIZ
  we'd previously end up truncating the line, which is stupid
  since we can just as easily make the buffer large enough.

Use ARGV_t for filelist current locale storage

- Avoids having to manually do search, sort, join, free etc for
  no good reason. Could be further simplified with argvSplit() etc
  and sanitized overall but leaving that for another day...

Eliminate redundant noGlob member from filelist

- Since the only thing where globs are not permitted are %dev entires,
  check for device explicitcly in the glob part. Doh.

Eliminate redundant special docs tracking members in filelist

Eliminate unused fileCount member from FileList struct

Add DWARF-4 support to debugedit (RhBug:707677)

Signed-off-by: Panu Matilainen <pmatilai@redhat.com>

Avoid extra newlines in parsed spec output outside preamble

Add --parse option to rpmspec tool to dump parsed spec contents

- This is somewhat like 'gcc -E', useful for analyzing/troubleshooting
  what happens inside the preprocessing.

Support retrieving the spec contents in parsed format

- Collect the preprocessed (conditionals, macros etc evaluated)
  lines to a separate stringbuf, make rpmSpecGetSection() return
  that on RPMBUILD_NONE "section" (hack, but so is abusing RPMBUILD_FOO
  for the section here so shrug)

Error on unclosed macros & trailing line continuations in spec (RhBug:681567)

- Track the starting line in case copyNextLineFromOFI() indicates
  a multiline-construct. If we get an EOF from readLineFromOFI()
  while inside multiline read, its an illegal construct of some kind
  and we can even spit out a reasonably meaningful error pointing
  out the starting line number of the bad construct.

Try to generate fileclass in the tag ext at runtime if missing from header
- For non-regular files we can easily generate this information based
  on file mode + in case of symlinks, the link target is available
  in the header elsewhere. This also means --fileclass will return
  at least partial data for packages built with the external depgen.
- Clean up fileclassTag() a bit while at it, removing redundant fluff.
- Arguably this "magic" should be done inside rpmfiFClass() instead, but
  that'd require changing the API to return malloced data.

Export rpmteFailed() to python bindings

- Kinda related to RhBug:661962, yum relies on callbacks to catch
  install/erase errors but this is not accurate: on erase the
  element can be ambiguous as the callback only gives a name (sigh).
  In addition, elements can be skipped entirely if "parent" element
  fails, in which case no callbacks are issued so these cases would go
  completely unnoticed when relying on callbacks alone. te.Failed()
  gives users such as yum a chance to have a look at the real status
  of elements (after the transaction).

Don't remove buildroot docdir on %doc usage (ticket #836)
- Some software installs its own documentation and if you try to
  combine it with %doc, rpmbuild will abort with mysterious
  "cpio bad magic" or such errors because what was assumed to be
  there was not, as %doc would 'rm -rf' the docdir upon first
  invocation. I don't see any good reason to disallow sharing the
  same directory for %doc and documentation installed by software
  "make install" - the other alternative would be forcing %doc to
  go to some other location, only making docs harder to find.
- Also at least Mageia (and prior to that Mandriva) has been doing
  this for quite some time now.

Adjust script detection rules to work with file >= 5.07 too (RhBug:712251)
- Somewhere between file 5.05 and 5.07 it started adding encoding
  to script descriptions, eg "<mumble> script text executable" became
  "<mumble> script, <encoding> text executable" breaking what had
  been working for 10+ years in the case of old find-requires.
- Permit either comma or space after "script", this works for both
  old and new file.

Add bunch of further rpm-python tests for this and that

Eww, python ds.Instance() doesn't take any arguments
- ...means its been broken all along, sigh

Add a bunch of db match/key iterator test-cases in python
- This would've caught the breakage introduced in commit
  7e4415fcc5e11cfd4cd9d0dfe19568be73f15d74, but better late than never...

Rearrange test-suite python helper macros a bit
- Handle double [] "escaping" at RPM_PYRUN to avoid surprises when
  its used on its own
- Spin python-wrapped AT_CHECK into a macro of its own (RPMPY_CHECK)
- What formerly was RPMPY_CHECK is now RPMPY_TEST: this represents
  one entire testcase with all its setup and cleanup, whereas
  RPMPY_CHECK (the new one) might be used several times within a
  single test

Fix the non-keyed match iteration case wrt DB_NOTFOUND
- This broke in commit 7e4415fcc5e11cfd4cd9d0dfe19568be73f15d74,
  the cases are not identical afterall: With non-keyed cursor
  retrievals DB_NOTFOUND is returned when there's nothing more to
  get, this is not an error situation.

Use dbiCursorGetToSet() for the non-keyed match-iterator case too

Support set append in dbiCursorGetToSet()
- If called with an existing set, results are appended. Otherwise
  return a newly allocated set.

If key not specified, use DB_NEXT cursor mode (DB_SET wouldn't make sense)

Only honor keylen if keyp is also specified

Make it an error to call dbiGetToSet() with NULL keyp
- All current callers always supply non-NULL keyp, and requiring
  this gives useful possibilities elsewhere

Move the remaining DBT's in rpmdbInitIterator() to (more) local scope

Error/notfound case is handled the same for both these cases

Take advantage of dbiCursorGetToSet() in dbiFindByLabel() & friends
- Reduces the number of arguments to somewhat saner level and
  eliminates another reincarnation of the dbt2set() + error handling
  code littered all over the place.

Split actual cursor get + set-conversion to separate function
- Allows multiple retrieves on a single cursor instance, dbiGetToSet()
  is just a convenience wrapper around dbiCursorGetToSet() now.
- Creating and tearing down cursors isn't exactly terrifyingly
  expensive but still measurable when lots of lookups are done.