streamline .gitignore further

adding some comments, regrouping files and use some patterns to avoid
updating the ignore file for new translations or abi changes

Git-Dch: Ignore
build the en manpages in subdirectory doc/en

Building manpages becames more consistent this way and
it is simpler to ignore build artefacts, too.
remove -ldl from cdrom and -lutil from apt-get linkage

Building src:apt shows:
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/apt/usr/lib/apt/methods/cdrom was not linked against libdl.so.2
(it uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/apt/usr/bin/apt-get was not linked against libutil.so.1 (it uses
none of the library's symbols)
rewrite pkgOrderList::DepRemove to stop incorrect immediate setting

Some squeeze → wheezy upgrades indicate that DepRemove runs amok
in complicated setups as it wasn't correctly working with or-groups.
Completely rewritten the check is now moving from or-group to or-group
instead.

The behavior should be the same as the code before, but
(hopefully) with less bugs and more comments.

Closes: 645713
prefer Essentials over Removals in ordering score

Doing Removes early is good to have them out of the way, so they
don't break 'Inst' or 'Conf' chains, but scoring them above Essentials
means that we end up upgrading (many) less important packages before
we handle big stuff like libc6 or debconf which not only fails if those
less important packages have unannounced (strict) dependencies, but also
leads to having these packages unconfigured for a long time triggering
bugs in maintainer scripts for no good reason (#708831).

So this commits sets the default value for remove scores to 100, which
is below the one for essentials (200) and a lot lower than the previous
default value (500).
fix priority sorting by prefering higher in MarkInstall

Used to work until a certain (here unnamed) person came along and used
the wrong operator causing low-priority packages to be sorted above
high-priority packages while choosing a provider in commit
 2b5c35c7bb915dbd46fefd7c79f05364ba22f93b from Nov 2011
try all providers in order if uninstallable in MarkInstall
do unpacks before configures in SmartConfigure

Splits the big loop over dependencies in SmartConfigure which unpacks and
configures dependencies into two loops and reverse their order, so that all
dependencies which need to be unpacked are handled first and only after that
configures are issued for dependencies.

This is needed as otherwise the unpack of a (new) dependency will be issued
in between a configure call for two (or more) packages which form a loop,
which means the configure calls aren't part of the same dpkg call and
therefore dpkg bails out.

Such tight loops should really be avoided as they are usually wrong – and in
reality the dependencies in libreoffice were greatly simplified thanks to
Rene Engelhard so the problem is gone for the benefit of all.

Closes: 707578
deprecate InstallProtect as a cpu-eating no-op

In the past packages were flagged "Protected" so that install/
remove markings where issued before the ProblemResolver.
Nowadays, the marking methods check if they are allowed to modify
the marking of a package instead, so that markings set by FromUser
calls are not overwritten anymore by automatic calls which elimates
the need for InstallProtect which just eats CPU now.

The method itself is left untouched for now in case frontend needs it
still for some wierd usecase, but they should be eliminated.
initialize the whole search array with zero

Git-Dch: Ignore
fix support for multiple patterns in apt-cache search

Patterns can appear in the name as well as in the description,
they don't have to match all in the name/description only.

Closes: 691453
make the vprintf like _error->Insert public

Git-Dch: Ignore
set Fail flag in FileFd on all errors consistently

Previously some errors would set the Fail flag while some didn't
without a clear reason as all errors leave a bad FileFd behind,
so we use a helper now to ensure that all errors set the flag.
don't explicitly init ExtractTar InFd with invalid fd

The default constructor of the FileFd will kick in anyway,
which will know that the Fd is invalid while with this explicit
call it must be assumed that the fd is in fact valid, which
might generate errors in the future
OpenDescriptor should autoclose fd always on error

OpenInternDescriptor failures would cause additional errors to be
generated by double-closing an fd. Other errors (although these
 are generated if the method is used incorrectly, so unlikely)
didn't close the fd aswell.

Closes: 704608
tests: trap-adding can be post- as well as prefix

For testcases it might sometimes be handy to add trap-actions
before the general cleanup, e.g. if it has set directories read-
only which rm doesn't want to remove even with --force applied
(its fine with files though)

Git-Dch: Ignore
tests: add expected port for cve-2013-105 testcase

Git-Dch: Ignore
depend on libapt-pkg in the libapt-inst build process

fixing parallel build in the handcrafted buildsystem is a pain,
so its not enabled by default, but its works for me – sometimes

Git-Dch: Ignore
stop building l10n if strings are unchanged

The buildsystem tried to build l10n for test applications which never
produced the output it expected causing it to try building it all the
time.
fail in CopyFile if the FileFds have error flag set

Testing for global PendingErrors in users of CopyFile is incorrect
in so far as unrelated errors will prevent us from copying perfectly
fine files and checking for the validity of the files is just better
in CopyFiles as it already checks if files are at least opened.

Add also a higher-level error message to the error stack if it fails.