Return fingerprint lookups through retval pointer, not struct

- Returning structs by value is a bit icky, pass in a fp pointer
  for fpLookup() to fill in instead. This leaves the actual return code
  free for handling errors (but ignoring that for now as we always have)
  The other option would be always mallocing the return, and we dont
  want to do that...
- Shouldn't change any actual functionality.

Avoid double iteration on 'rpm -e' now that iterator count works

- While harmless, having to count on one and act on another iteration
  gets expensive when there are lots of labels specified. Especially
  as the iterator initialization can already load the same headers
  multiple times, sigh...

Push RPMDBI_LABEL arch parsing down to rpmdb layer to fix stuff

- Partial NEVRA labels cannot be reliably parsed, the various combinations
  need to be figured out by trial-and-error. The rpmts layer doesn't stand
  a chance of getting it right so move it to rpmdb layer. This doesn't
  make the process any less stupid, but at least we get correct results...
- Fixes iterator count when arch is used in a label and more than one
  arch variants of a package are installed. Previously iterator count
  could be more than one despite actual iteration only hitting one
  match, as the arch RE match was added after already initializing
  the iterator.
- Also fixes various pathological cases:
  - If a legal arch was part of name, version or release (stupid but legal)
    we misinterpreted it for arch and failed to find the package.
  - If a package with unknown architecture was installed (with --ignorearch)
    we could not remove it by its arch as we relied on rpmIsKnownArch()

Use existing fingerprint for packages being removed

- Missed opportunity in commit 1a3a4089def9b00790eeebd6f931c99a03a3d44b:
  removed packages have already gotten fingerprinted so there's no need
  to redo that here.

Shut up gcc whine about potentially uninitialized variable

- This is a false positive really, or at least a cant-happen case

Avoid rehashing directory name when it doesn't change in rpmal population

- Another modest improvement in redundant rehashing elimination, but in the
  big picture, this is really just another fart in the Sahara desert...

Prehash dir names on fingerprinting to avoid recalculating when adding

- Speedup depends on transaction and yadda yadda, on my large erasure
  transaction testcase this is circa two percent saving on rstrhash()
  total costs.

Use helper variable to eliminate multiple identical conditionals

Prehash dependency strings to avoid recalculating when caching

- Speedup depends on the transaction and is likely to be rather modest
  anyway, but can't hurt either...

Prehash basenames to avoid recalculation when adding new ones

- Speedup depends on the transaction and is by no means enormous,
  but on my testcase of a largish erasure transaction this shaves
  off circa four percent of the cycles spent in (re)hashing the
  basenames.

Add alternative hash key add/get/check methods with prehashed key

- In cases where more than one operation is done with the same key, these
  can be used to avoid the relatively expensive rehashing of the key.

Add hash table methodn for (pre)calculating base hash of a key

Minor optimizations to rpmvercmp()

- Avoid calculating string lengths if versions are equal
- Avoid calculating string lengths twice in numeric comparison

Minor optimization to rnibble()

- Check for lowercase letters before uppercase. A very minor difference
  as such, but our file digests use lowercase hex and this gets
  called a lot from rpmfiNew().

Avoid netshared path matching when netshared path is not set

- We've been calling matchNetsharedpath() for every single file in
  the transaction regardless of whether %{_netsharedpath} is set or
  not (and almost always it is not), meaning lots of pointless
  strlen() calls and in case of erasure, rpmfi iterations performed.
  Not exactly a massive speedup but a speedup nevertheless.

"Optimize" addFingerprints() a bit

- Avoid repeatedly calling rpmteGetFileStates() for every file processed
- Avoid rpmfi iteration, use a good ole for-loop and index-accessors
- Dont bother looking up symlinks for skipped files
- Eliminate rpmfi from the latter loop, its not used for anything there
- Not that this is going to show on wall-clock times, the cycles saved here
  are going to get very much lost in the noise of more expensive things.

Avoid unnecessary calculations on %ghost %config

- If the replacing %config file is a %ghost, then we'll just leave whatever
  might be on disk alone.
- OTOH in the opposite case we probably *should* take backups, if the
  file exists on disk and is differs from the new non-ghost (but
  currently we take never take backups for %ghosts)

Only backup if osuffix is set

- This can happen on %ghost files, fsm->ossufix is never set for them.
  Arguably this is a bug in the file disposition calculations but for now...

Fix memleak regresssion in rpmfiDecideFateIndex()

- Similar to commit 80ee39da35544253cab12abd54af8754335ac945: this
  started leaking at commit 3f996a588a56141df146c33583a13c0542323977
  as rpmfiFNIndex() returns malloced memory. Refactor the lucky 13
  return points into one, allowing cleanup at exit.

Cache the actual result on rpmdb header verification

- Previously we'd turn all but FAILED results into "OK" after first
  check, now we return the real value. And perhaps more importantly,
  no longer try re-verifying previously failed headers in vain.

Use file info set of removed packages instead of header fetches

- When we get rpmdb hits on files from packages that are to be removed
  in the same transaction, we can use its existing file info set
  to grab base- and directory names to avoid bunch of headerGet()'s
  and consecutive rpmtd manipulation. In theory this should speed up
  transactions where lots of packages get removed, in practise not
  really - the big cost here is in loading the headers from db in the
  first place, despite not being really needed.

Use file info set of removed packages instead of new temporary one

- When we get rpmdb hits on files from packages that are to be removed
  in the same transaction, we can use the exisiting file info set
  to avoid constructing a new temporary one. Might be measurable
  in large updates.

Store transaction element pointers in the removedPkgs hash

- Change the hashtype name to something else, its no longer a plain
  int hash. Still needs double definition as its not contained in
  a single source (might want a wrapper similar to rpmal), but
  slightly more contained now than the previous intHash definition.
- This opens up some new possibilities, to be taken advantage of
  in later commits.

Define separate hash for rpmdb header check cache

- This is really private to rpmdb.c (other than being exposed in
  the struct definition in backend/dbi.h, sigh), let it live its
  own life there.
- No functional changes here, just cleaning up a bit for next steps.
  OTOH we could now cache the actual result, not just success... but
  leaving that to another time.

Oops, undefining wrong name...

Split colored conflict resolution to helper function, unify callers

- The cases in handleOverlappedFiles() and handleInstInstalledFile() only
  differ by presence of "other file state", unify the copy-paste code
  to helper function and comment a bit more.
- Push all the color fiddling into the helper, eliminating loads of
  unnecessary rpmfiFColorIndex() calls in the common case. Also gives
  us a single point of control for the color-conflict behavior.
- This is not supposed to change any behavior at all, just refactoring...

Eliminate redundant helper variable

- Just use the file action to determine if we already decided something
  for this file or not, no need for additional helper trackers.

Differentiate between filtered and otherwise resolved new conflicts

- Kinda similar to commit 12322bad67b809101017a3991e67d09a2af4803c but for
  conflicts among the added set: grab the conflict filtering flag once
  outside the loop and use to determine whether to report detected
  conflicts or not. Doesn't change actual functionality.

Add further multilib resolution test-cases

- Also test for the cases where packages are installed in different
  transactions, the outcome should be exactly the same in every case
  regardless of the order.
- Change the expected output to something slightly more readable for
  us humans

Tweak the conflict test descriptions a bit

Oops, replacetest spec missing from dist tarballs

- Should've been in commit 0bbcbb050d3a1d93eafa5ee353d4b89a9946b68f

Detect attempts to replace directory symlink to directory in package

- Rpm cannot currently *correctly* deal with directory symlink changing
  to a directory through updates, detect early and abort with conflicts
  instead of proceeding with known-broken results: previously these
  would seemingly succeed but without actually doing the requested
  changes, and leaving orphans on the disk. Far less evil than the
  directory replacement failure but incorrect anyway.
- Same %pretrans wackiness as with directory replacements applies here.
- Adjust test-suite to match the new behavior.
- It's possible there are packages that have been relying on the former
  broken "success" results, so this might need further fine-tuning...

Detect attempts to replace directories and report as conflicts

- Rpm cannot currently deal with directory changing to something else
  through upgrades. Until now we've barfed up an ugly error in the
  middle of transaction, leaving partially installed broken junk behind.
  It'd sure be nice to be able to actually handle this some day, but
  until then detecting and aborting early is a far better option than
  the former behavior.
- There are some "only in rpm" level bizarre quirks here: packages
  can work around this limitation by using a %pretrans scriptlet,
  which runs before the conflict detection. But this means a possible
  test-transaction (as done by eg yum) will still see the conflicts,
  as we obviously dont want to run disk-modifying scripts on
  test-transaction. So when looking at these removal conflicts, we filter
  them out on test-transaction IFF the package has a %pretrans script
  so there's a chance it might actually fix the conflict when we get
  to it in a real transaction. Obviously %pretrans from any package
  could in theory fix such issues, but as this is evil enough as it is,
  try to limit the damage... Without %pretrans, the only other option
  to get around these is manual intervention.

Add pile of new test-cases for file type changes in upgrades

- Of particular interest is directory changing to something else
  (including the infamous symlink case), which we miserably fail
  currently. Until we can somehow manage them someday, we should
  abort early (by conflicts) instead of barfing up garbage in
  middle of transaction.

Clean up testroot /opt throughly to avoid other test from affecting us

Make rpmteHaveTransScript() available internally

Differentiate between filtered and otherwise resolved conflicts

- No functional changes here, just spelling out the different
  cases explicitly.

Remove unused leftover variable

- Should've been in commit a3a08a4b0aa96ae03c33050920baf894cc706c9e

Axe the if-what jungle in rpmfiDecideFateIndex()

- Unless the file does not exist on disk, we cannot determine the
  correct action for config files and symlinks before we actually
  check them. Those are also the only types that *can* result in
  FA_ALTNAME/FA_SAVE action, anything else we can just create.
  Besides making the logic a whole lot easier to follow, it also
  fixes our remaining test-case failures. Who would've thought?
- Might be worth noting that this requires the pile of fsm fixes
  from previous commits to work.

Backing up contents when replaced by directory needs special handling

- When a directory is about to replace a %config needing backup,
  we need to backup early as directories don't use a temporary
  path, and fsmVerify() will remove the file before we get to
  it in fsmCommit().

Use fsm->action to decide whether we need a backup or not.

- We already have a carefully precalculated action decided for these
  things, use that instead of bunch of arbitrary (except for osuffix)
  conditions depending on several nasty hacks and hidden assumptions.
  Doing so fixes stuff, who would've thought of that?
- Adjust test-suite expectations

Backup filename needs suffix, whether its directory or not

Remove dead file-backup code

- fsmVerify() never ever returns 0 for regular files because of
  multiple hacks in how this all "works": on install, we skip stat()
  but claim disk checked and file not existing, so fsmVerify() returns
  early. Good thing it does too, as otherwise it would remove the
  file we were supposed to be saving here. The actual %config backup
  occurs in fsmCommit(): regular files are first installed with a
  temporary suffix and at "commit" time we decide whether it needs
  backing up or not (involving several other hacks...)

Simplify the non-modified config file vs directory test

- Replacing a directory with something else is more complicated than
  other cases and deserves tests of its own. For simplicity in
  the config cases, remove the "and back" part of the test, and
  now this test actually succeeds.

Doh, gotta love it when test-suite expectations are wrong.

- Clearly if we have three cats we should be seeing three outputs as well...

Fix a massive memleak from rpmfiConfigConflictIndex() and optimize it

- rpmfiFNIndex() returns a malloced string since commit
  11116a67864c119e420297984bd9ec4b83fdadd7 but this wasn't taken into
  account in commit 3f996a588a56141df146c33583a13c0542323977, causing
  a massive memory leak on transaction preparations.
- Optimize the entry by avoiding rpmfiFNIndex() and lstat() until
  really necessary, and use a central exit point beyond that so
  we can free fn. Besides fixing the memleak, this gives a small
  but measurable performance improvement on this rather busy path.

Use rpmfiConfigConflictIndex() for modified config testing on erase too

- Besides eliminating another copy-paste variant of the config file
  digest calculation and comparison, this fixes the case modified
  %config symlink gets silently erased. Unlike a regular config file,
  a symlink does not contain a whole lot of carefully tuned data, but
  if it's marked %config I think we should honor the %config file rules.
- Adjust test-suite expectations to match the new behavior.

Polish the symlink config file comparison a bit

- Similar treatment as in commit 9f9ed70e2d85b0e8f5e2d9cf9969046034d9ad31,
  pay more attention to what kind of files we're comparing in each case,
  add a little breathing room and extra comments.
- Handle the case where on-disk link is identical to the one in new
  package in which case no backup will be needed, fixing two cases
  of unwanted backups in the test-suite.
  (similar to commit 7a50e9de80ab3c47618dad1e9a5b2d9b79bfc8dc)
- Other than the on-disk vs new package change, probably doesn't change
  anything yet, but prepares us for the next steps.

Polish the regular config file comparison a bit

- Only return early in the cases where backup will NOT be needed.
  Pay more attention to what kind of files we're comparing in each
  case, add a little breathing room and extra comments.
- This probably doesn't change anything as-is, but hopefully makes
  the logic a bit easier to follow and prepares us for the next steps.

Cosmetics: compare memcmp() return code explicitly

- Comparing against zero is just that little bit more readable
  than the negated condition.

Erm, remember to actually enable all the new tests

Add a third set of config tests for file type changes testing

- Several (expected) breakages here too, some backups missing, and
  some redundant backups taken
- This is by no means complete set of the possible changes but
  gotta start someplace...

Add similar set of %config tests on symlinks

- Several cases are (expectedly) broken here: sometimes backup not
  taken when wanted, sometimes redundant backups taken

Prepare config test-suite to cleaning up directories

Further parametrize the config test spec file to allow more cases

Fix %config backup on erasure regression

- After commit 1845c1d711b88723e596c88e8a7730a360029089 erasure
  no longer calls fsmCommit(), missing the backup step entirely.
  Simply split the backup code to a function of its own and call
  as needed. The details look somewhat fishy but what in fsm doesn't...

And yet more %config test-cases

- Test behavior when installing over a pre-existing file
- Test behavior on erasure
- Two of the erasure-tests are currently failing due to regression
  introduced in commit 1845c1d711b88723e596c88e8a7730a360029089

Dont create redundant %config backups when on-disk content is same as new

- When on-disk %config file contents match the contents of the new
  package (such as config in old package was buggy, fixed in new
  and admin worked around in the meantime) there's no point creating
  a backup that's identical to what you already have. Note that
  we create the new config anyway instead of skipping as timestamp
  might have changed.
- Adjust test-cases to the new saner behavior.

Cosmetics: remove unnecessary line-wrap

Dont create %config backups on skipped files

- This cosmetical only, but there's no point creating the same backup
  twice. Depends on commit f7f5f88f9f3d6587e747b034ccb64a3f00ff4e1e.

Test that the %config backup contents are what we expect

- Note we're only checking the contents where backups *should* be
  created, not much point checking buggy behavior.

Yet more %config test-cases - shared configs have quirks of their own

Add similar set of %config(noreplace) tests

- The first tests are kinda redundant but extra tests never hurt anybody...

Adjust the config test descriptions a bit to make room...

Add further "parametrization" to our config file test spec

- Currently unused but to allow for testing further cases with the
  same base spec...

Add a test-case for another %config file special case

- When an existing config file content changes between package versions
  but the file has already been changed to match the content of the
  new version, we still create a backup file that's identical
  to the one that ends up being installed. This is a bug of sorts,
  but documenting the existing behavior before changing it.

Tighten the existing %config tests a bit

- Test for actual file content
- Also clean up any .rpm[new|save|orig] files from the testroot

Add a test-case for the shared file timestamp behavior

- Prior to commit f7f5f88f9f3d6587e747b034ccb64a3f00ff4e1e, this
  would've failed: removing the last package to be installed would
  cause timestamp failure on all others. The order is arbitrary in
  this testcase but it matters in real-world situations such as
  secondary arch packages.

Only create the first instance of a file shared between packages

- When packages share an identical file, we only need to create the
  first one we encounter and skip it for the rest (reverse already
  happens, and must happen, on erase). This has the benefit of
  getting the timestamp to match the first file, which often is
  also the last one to get removed. Also when lots of shared files
  are involved (such as in multilib installations), this can give
  several percents worth of speed gain as we dont unnecessarily rewrite
  the same contents over and over.

Blargh, more fdFree() braindamage

- Commit 429b933b42d1821f6f0a2a41ae13c504ea6d0657 fixes the fd-leak
  regression in rpm 4.10, but we already have code which relies
  on the new behavior and segfaults with the former one. Adjust
  rpmcpioClose() to the old behavior to get master tree back to
  working shape. TODO: fix this properly some rainy day (oh and see
  http://geekandpoke.typepad.com/geekandpoke/2012/08/likelihood.html)

Revert "Always return NULL from fdFree()"

- This reverts commit 4c1f7e335de1724661ce63c53186d161ab71a63f:
  various things inside and outside of rpm actually do still depend
  on the old behavior, and leak file descriptors otherwise.
  As an easy backportable band-aid, revert back to the previous
  behavior, to which various callers are tuned to fix the regression
  introduced in rpm 4.10.0. The real fix would be something more like
  "eliminate fdFree() and make Fclose() honor refcounts".

Run gcc supported flags test without our stricter warning flags

- Fixes fallout from commit f9c69f803f74bd458269c7a06def494ea63387e6:
  running these tests with -Wstrict-prototypes causes all these tests
  to fail as AC_LANG_PROGRAM() uses an incomplete prototype for
  main() :(

Fix bogus "unclosed %if" error when %include is used in conditionals

- All rpm versions log a bogus "unclosed %if" error when %include
  is used inside %if-%endif (and rpm >= 4.10 actually aborts the
  parse): the check for unclosed if occurs before checking whether
  there's more to come.
- Move the error check into readLine() EOF path along with the other
  similar check to fix, and to consolidate the error handling to
  a single spot.

Add test for file verification from originating package

Verify files from non-installed packages again (RhBug:826589)

- Verifying files against the originating, non-installed package can
  be useful sometimes, eg if rpmdb is broken or cannot be trusted.
  Of course such verification will give false positives on files that
  were intentionally skipped during installation (nodocs, wrong color,
  netshared...), that can't be helped.
- This restores the former behavior that was erroneously changed
  in commit adbd484372cb38aca5aca3c6dba3b2ca9cae93d1 while "fixing"
  an unhandled enumeration in the switch. Doh.

Accept em64t architecture as an alias for x86_64 (RhBug:800489)

- Some vendors insist on calling their x86_64 packages "em64t" instead
  of the more standard x86_64. Minimally support this naming convention
  as those packages aren't going away anytime soon - be liberal in
  what you accept and all, sigh.

Add tests for invalid --relocate detection and --badreloc functionality

Fix RPMPROB_FILTER_FORCERELOCATE aka --badreloc (RhBug:828784)

- As noted (but since then blissfully forgotten) in the commit message,
  commit e696b409fe836bf39cbf639bac4321d658d0952d broke --badreloc
  so its been broken since rpm >= 4.9.x :-/
- Transaction problem filter is only available during rpmtsRun() so
  we have no clue whether bad relocations should be filtered or not
  during rpmte creation. Instead of creating the problems at rpmteNew()
  time, remember any bad relocations that were found and check +
  create the actual problems (unless filtered) along with other
  problems during rpmtsRun().
- Passing an "allow bad relocations" flag to rpmtsAddInstallElement()
  would be a saner option but this is a back-portable way of handling it.

Handle all dependency tags in spec via same switch-case fallthrough

- Requires and OrderWithRequires take extra qualifiers, but other
  than that they areall handled the same through parseRCPOT()

"prereq" is not a valid qualifier to regular Requires

Extra qualifiers like (postun) are not valid with legacy PreReq

Honor RPMSENSE_MISSINGOK flag in dependency checking

- For now there's no way to set this flag from packages so it doesn't
  actually do anything, but it doesn't hurt anything either, allows
  Suse & friends to drop one patch (greetings Michael :) and there
  are might be some things we could use this for internally.

Dont silence patch by default (RhBug:678000, RhBug:773503)

- Unfortunately patch'es idea of "interesting" output is not ideal for
  our purposes: "patching foo.c" is of little value, but hunks with
  offsets and fuzz can be important and there's no switch to patch
  to get exactly what we want. So let it be chatty... build logs are,
  anyway.

Add --noclean and --nocheck options to rpmbuild

- Ability to skip %clean build stage was requested as RhBug:756531,
  --nocheck seems otherwise useful to have as %check can take a lot of
  time, time you might not want to spend for a trivial spec change or such.

Fix memleak in changelog parsing on error paths

- All the early returns would leak memory from the argvJoin(),
  assume failure and force all exits through a single path where
  we can clean up.

Turn the invalid date error to warning (related to RhBug:843525)

- The strict date validation introduced in commit
  a29e5f9894e4d97322d34b0636e5a37bff509323 is too much of a PITA
  for such a petty cause, mismatching weekday names as very very
  common in specs. Maybe we can change it to a hard error in a couple
  of years from now once folks have had time to get rid of the
  warnings first.

Refactor the struct stat hacking into a helper function

- Shouldn't change actual functionality, just makes the code easier
  to read and fit on screen by reducing indentation level.
- Add further commentary about what it does and why.

Permit non-existent %ghost directories to be packaged (RhBug:839656)

- Directories can be explicitly specified via either %dir or trailing
  slash in the %files manifest, take this into account for %ghosts that
  dont exist in the buildroot. Otherwise we still assume regular file.
- Dont require explicit %attr() for missing %ghosts, let them fall
  back to %defattr() instead. If %defattr() doesn't specify a mode
  the file will be seen without any permissions at all, but that's
  not strictly an error (and same can happen with %dev() already)

Dont bother asking libmagic about directories

- There's no (relevant) additional information to be gained from passing
  directories to libmagic and we already have this info available in the
  file mode. This permits nice and easy handling of %ghost directories
  (related to RhBug:839656)

Report starting line for unclosed %if in specs

Dynamically grow spec line buffer on line continuations

- Allows arbitrary length line continuation constructs in specs, but
  probably the more useful side-effect is cleanly handling unterminated
  macros and the like (instead of segfaulting) on large spec files,
  there was a bug on this somewhere but cant find it atm.
- This also has a wee bit silly effect on the maximum macro expansion size:
  after very long constructs the max expansion gets is bigger than
  at the beginning of spec parse, but properly fixing the resizing wrt
  macros is a different issue.
- Watch out for possible fallout from spec->line etc tracking, they
  *seem* to be ok even with the potentially moving buffer location but...

Minor cleanups: const pedantry and helper variable scoping

- Make the reading pointers const, push helpers to scope where needed

Allocate spec line buffer separately from spec struct

- Further preliminaries for dynamic buffer resizing

Track spec parse buffer position by offset instead of pointer

- Preliminaries for dynamically reallocating the buffer

Fix (well, loosen up) the valgrind suppression rules

- The previous rules far too specific to glibc + gcc with certain
  optimization levels, eg relying on parse_auxv() getting inlined
  and when it does not, the suppression rules would no longer match.

Stricter validation of changelog date (RhBug:843525)

- Compare the date parsed from changelog to date normalized by mktime()
  and complain if they differ. This catches cases like wrong weekday
  specified for an otherwise valid date, and a leap day on a non-leap
  year etc.

Always print out package dependencies on build

- Previously packages which had no files or for which automatic
  dependency generation was partially or fully disabled didn't get
  any of their dependencies printed out at build-time. This doesn't
  affect the actual recorded dependencies, only the "debugging"
  output during package builds.

Run gcc supported flags test with -Werror

- On gcc versions supporting -fstack-protector, not all platforms
  support this feature, causing gcc to emit only a warning instead
  of an error. Which then causes warning-spew on every compiled file.
  Run all the supported flag tests with -Werror to turn the warnings
  into errors, there could be other similar cases besides stack protector.
- Patch originally from Arnaud Patard according to this Mandriva commit:
  http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages?view=revision&revision=448632

Report config and missinok flags in deptype format extension too

Default to automatic patch application in %autosetup

- Defaults should be for the common case with disablers for those who want
  to do something special, and typically if you have patches you also
  want to apply them. Change it while we still can: eliminate -A option to
  %autosetup and apply all patches unless -N option is used.