Merge branch 'debian/sid' into debian/experimental

Conflicts:
	apt-pkg/cachefilter.h
	apt-pkg/contrib/fileutl.cc
	apt-pkg/contrib/netrc.h
	apt-pkg/deb/debsrcrecords.cc
	apt-pkg/init.h
	apt-pkg/pkgcache.cc
	debian/apt.install.in
	debian/changelog

1 files changed, 0 insertions, 63 deletions

diff --git a/README.MultiArch b/README.MultiArch
deleted file mode 100644
index 588419b8d..000000000
--- a/README.MultiArch
+++ /dev/null
@@ -1,63 +0,0 @@
-Before we start with this topic: Note that MultiArch is not yet ready for
-prime time and/or for the casual user. The implementation is so far widely
-untested and only useful for developers of packagemanagment tools which
-use APT and his friends and maintainers of (upcoming) MultiArch packages.
-This README is especially NOT written for the casual user and is NOT a
-usage guide - you have been warned. It is assumed that the reader has
-at least a bit of knowledge about APT internals, dependency relations
-and the MultiArch spec [0].
-
-Note also that the toolchain isn't ready yet, e.g. while you can simulate
-the installation of MultiArch packages they will more sooner than later
-cause enormous problems if really installed as dpkg can't handle MultiArch
-yet (no, --force-{overwrite,architecture} aren't good options here).
-Other parts of the big picture are missing and/or untested too.
-You have been warned!
-
-
-The implementation is focused on NOT breaking existing singleArch-only
-applications and/or systems as this is the current status-quo for all
-systems. Also, many systems don't need (or can't make use of) MultiArch,
-so APT will proceed in thinking SingleArch as long as it is not explicitly
-told to handle MultiArch:
-To activate MultiArch handling you need to specify architectures you
-want to be considered by APT with the config list APT::Architectures
-(Insert architectures in order of preference).
-APT will download Packages files for all these architectures in the
-update step. Exception: In the sourcelist is the optionfield used:
-deb [ arch=amd64,i386 ] http://example.org/ experimental main
-(This optionfield is a NOP in previous apt versions)
-
-Internally in APT a package is represented as a PkgIterator -
-before MultiArch this PkgIterator was architecture unaware,
-only VerIterators include the architecture they came from.
-This is/was a big problem as all versions in a package are
-considered for dependency resolution, so pinning will not work in all cases.
-
-The problem is solved by a conceptional change:
-A PkgIterator is now architecture aware, so the packages
-of foobar for amd64 and for i386 are now for apt internal totally
-different packages. That is a good thing for e.g. pinning, but
-sometimes you need the information that such packages are belonging together:
-All these foobar packages therefore form a Group accessible with GrpIterators.
-Note that the GrpIterator has the same name as all the packages in this group,
-so e.g. apt-cache pkgnames iterates over GrpIterator to get the package names:
-This is compatible to SingleArch as a Group consists only of a single package
-and also to MultiArch as a Group consists of possible many packages which
-all have the same name and are therefore out of interest for pkgnames.
-
-
-Given all these internal changes it is quite interesting that the actual
-implementation of MultiArch is trivial: Some implicit dependencies and a few
-more provides are all changes needed to get it working. Especially noteworthy
-is that it wasn't needed to change the resolver in any way and other parts only
-need to be told about using GrpIterator instead of PkgIterator, so chances are
-good that libapt-applications will proceed to work without or at least only
-require minor changes, but your mileage may vary…
-
-
-Known Issues and/or noteworthy stuff:
-* The implementation is mostly untested, so it is very likely that APT will
-  eat your kids if you aren't as lucky as the author of these patches.
-
-[0] https://wiki.ubuntu.com/MultiarchSpec